Exit nodes: offer one per network, send all traffic through a member

A member can offer itself as an exit node per network (off by default); it is
announced over the control channel (ctrl/4) once its iptables masquerade and
forward rules are in place, with a warning when kernel forwarding is off. A
device picks one member as its exit node via policy routing, with the agent's
own uid exempt from the tunnel; if the exit node disappears the rules stay
and traffic is dropped, loudly reported. CLI: `network exit-node`,
`exit-node`; tray: tile checkbox, warnings and a per-device icon with
confirmation. Linux only.

Co-Authored-By: Claude <noreply@anthropic.com>

docs/exit-node.md

@@ -0,0 +1,75 @@
+# Exit nodes
+
+A member can offer itself as an **exit node** in a network. Other members can
+then send *all* their internet traffic through it, the way a commercial VPN
+or Tailscale's exit nodes work. Linux only for now.
+
+## Using it
+
+The offering side, per network, off by default:
+
+```sh
+tsunagi network exit-node <network> on      # or off
+```
+
+Rules are installed even when the kernel does not forward yet, and `status`
+says so. Turning forwarding on is left to you, on purpose:
+
+```sh
+sudo sysctl -w net.ipv4.ip_forward=1
+```
+
+The using side:
+
+```sh
+tsunagi exit-node                  # who offers one
+tsunagi exit-node <name|id>        # send everything through it
+tsunagi exit-node off
+```
+
+The tray does the same: a checkbox on the network tile to offer, and an icon on
+each device in the devices window that offers one, with a confirmation.
+
+One device has one default route, so it uses **one** exit node at a time;
+choosing another replaces the first. Offering is per network, so a device can
+be an exit node in one network and not in another.
+
+## How it works
+
+- An offering agent says so in its control-plane `Announce` (`exit_node`), and
+  only once its rules are in place. Members see which peers offer one.
+- **Server:** `iptables` masquerades the overlay range of that network out of
+  any other interface and allows forwarding for it. Rules carry the tag
+  `tsunagi-exit:<interface>:<range>` and are removed when the offer ends, the
+  network stops, and when the agent exits. Only networks that offer have
+  rules, so the others' traffic is not forwarded.
+- **Client:** policy routing, with no change to the main table. Table `28787`
+  holds `default dev <interface>`, and three rules sit after Tailscale's:
+  `5280 uidrange <agent uid> lookup main` (the agent's own connections never
+  go through the tunnel, which would be a loop), `5290 lookup main
+  suppress_prefixlength 0` (LAN and other specific routes keep working) and
+  `5300 lookup 28787`.
+- Packets for addresses outside every overlay range are sent to the exit node
+  by the router; the exit node's replies are accepted from any source. A member
+  that is not your exit node cannot do that.
+
+## What it does not do
+
+- **The agent must run as a system service** (its own user). The uid exemption
+  would otherwise cover everything you run. A per-user agent refuses to use an
+  exit node and says why.
+- **If the exit node disappears the rules stay** and traffic is dropped until
+  it returns or you run `tsunagi exit-node off`. This is deliberate: falling
+  back to the direct path would leak traffic nobody agreed to send in the
+  clear. The agent logs it once, `status` and the tray say so loudly.
+- IPv6 and DNS are untouched. IPv6 traffic still leaves the ordinary way.
+- Kernel forwarding is only read, never changed.
+
+## Trust
+
+Anyone who knows the network's secret can pick your exit node if you offer
+one, and you carry what they send: it leaves from your address and is yours to
+answer for. The exit node sees every destination and, for plain traffic, its
+contents. Choosing an exit node means trusting its owner completely. Offer one
+only in networks whose members you trust, and only from a machine you are
+willing to have that traffic come from.

docs/protocol.md

@@ -9,7 +9,7 @@ Two versions exist and are independent:
 
 - **Identity scheme**, `tsunagi-network-id-v1`. Frozen. Changing it creates a
   different network space for the same name and secret.
-- **Control protocol**, ALPN `tsunagi/ctrl/3`, `PROTOCOL_VERSION = 3`.
+- **Control protocol**, ALPN `tsunagi/ctrl/4`, `PROTOCOL_VERSION = 4`.
 
 Upgrading the crate or bumping the control protocol must never change an
 existing `NetworkId`.

docs/routing.md

@@ -86,5 +86,5 @@ counts sends without storing frames. Results are CPU forwarding cost, **not**
 end-to-end network latency or VPN throughput; encryption, fragmentation,
 sockets, congestion and scheduling contribute separately.
 
-Wire compatibility: control ALPN `tsunagi/ctrl/3`, data ALPN `tsunagi/data/4`.
+Wire compatibility: control ALPN `tsunagi/ctrl/4`, data ALPN `tsunagi/data/4`.
 Upgrade every participant together; saved identities and network state persist.

docs/threat-model.md

@@ -69,6 +69,10 @@ Read this before relying on anything here. The protocol is in
   punch, the data connection goes through a relay, which then sees the volume
   and timing of tunnelled traffic — though not its contents, which WireGuard
   encrypted, nor the iroh layer's contents.
+- **Exit nodes.** A member that offers one carries other members' internet
+  traffic and sees where it goes; a member that uses one trusts it completely.
+  Anyone holding the network secret can use an offered exit node. See
+  [exit-node.md](exit-node.md).
 - **Overlay address squatting.** A member can mint many WireGuard keys and
   therefore occupy many overlay addresses. It cannot pick which ones, but it
   can consume them and appear as many participants.