feat(marketplace): the filter that stops one customer being another

API_CHANGELOG.md

@@ -58,6 +58,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 
 - **The route server now routes its tunnel pool's own blocks.** An address on a point-to-point interface does not route the rest of its prefix, so a route server holding `10.66.0.1/16` answered "network is unreachable" for every node in that pool — the peers were configured correctly and unreachable. Found by an end-to-end harness that builds both ends of a tunnel and sends real packets, not by review.
 
+- **A node's status now reports the packet filter around its guests** — `GET /status` on the node control API gains `dataplane.firewall`: whether the machine has a working nftables, whether LNVPS's ruleset is loaded, whether guests are isolated from each other at layer 2, how many guest bindings are enforced, which ruleset the *kernel* is running (a tag read back out of a rule comment, not remembered by the daemon), and how many packets have been dropped for claiming an address the guest was not assigned. That last number is the only one here that says something about a customer rather than a node: a guest that is spoofing is either compromised or hostile, and LNVPS would rather learn it from a counter than from an upstream abuse report. A node whose filter is not loaded now reports itself **unhealthy** — an unfiltered node is one where any guest can be any other, which is worse than a node carrying nobody.
+
 - **A node can fetch its whole data plane in one document** — `GET /api/v1/node/dataplane` (node token) returns the tunnel it already gets from `/node/tunnel`, plus the gateway addresses the node must answer for, and the guests assigned to it (address, gateway, MAC). One call rather than three because the node applies these together or not at all: a bridge with no tunnel carries nothing, a tunnel with no guest routes carries nothing back, and a document that can be half-fetched is a data plane that can be half-applied. The guest list is also the anti-spoof list — an address not in it is not that node's to send from. The gateway is the one the guest was actually configured with, taken from its IP range: it belongs to the range rather than to the node, and the guest believes it is on-link, so the node has to answer for it rather than invent one.
 
 - **A node takes one address, not a point-to-point link** — `address4`/`address6` in the tunnel response are now a `/32` and a `/128`, and `gateway4`/`gateway6` are one address shared by every node on the pool rather than a per-node link address. WireGuard is layer 3 and point-to-point: the node needs no gateway on its own side (`ip route add default dev wg0` suffices), so a `/31` spent two addresses describing something that needs one — and forced the route server to carry one address per node on a single interface, thousands of them on a /16 pool. Pool capacity is reported accordingly: a /24 places 253 nodes (256 less the block's network address, the route server's address after it, and the broadcast address) where it previously reported 128 links.