mirror of
https://github.com/jmcorgan/fips.git
synced 2026-10-05 19:18:25 +00:00
Johnathan Corgan
1eb0e8a34e
Bringing the TUN device and the .fips DNS responder up and taking them down is host-side work, but the bodies sat inline in the node's supervisor arms, and their handles were eight loose fields on the supervisor. Move the bodies to ipv6tun::lifecycle and gather the handles into one Handles struct there, held by the supervisor. The supervisor arms, their order and the child-exit reporting are unchanged; each arm now calls into ipv6tun. The TUN start is two calls so the node can refresh its MSS ceiling between them, exactly where it did before: open_tun creates and logs the device, then spawn_tun creates the macOS/FreeBSD shutdown pipe and starts the writer and reader threads. A failure to create the device still continues without a TUN, and a pipe or writer failure still fails the node's start. stop_tun and stop_dns carry the teardown unchanged, including the shutdown-pipe write that wakes the reader on macOS and FreeBSD. The TUN device name moves into Handles as well, so the teardown up-set can ask ipv6tun whether each child is up. A TUN counts as up when it has a device name, not when it has a sender, so an app-owned TUN still produces no TUN teardown; DNS counts as up while its task handle exists. Node::tun_name, tun_tx, dns_local_addr and enable_app_owned_tun keep their behaviour and now read or write the handles. Node::mesh_ifindex had no caller left outside a test and is replaced by the same method on Handles. Tests install a TUN sender through a test-only Node::install_tun. The moved log lines now log under fips::ipv6tun::lifecycle instead of fips::node::lifecycle. Add that target to the NAT harness and its trace overlay, and to the harnesses that relied on fips::node=debug, and note the rename in the changelog.
NAT Lab Harness
Real Docker-based NAT traversal integration tests for the mainline FIPS Nostr/STUN bootstrap path.
This harness spins up:
- two FIPS nodes
- a local Nostr relay
- a local STUN server
- one or two Linux router containers performing NAT with
iptables
For the NAT scenarios, the node LAN interfaces are not attached to
Docker bridge networks. The harness creates explicit veth pairs and
moves them into the node and router namespaces after docker compose up
so every packet must traverse the router namespace.
It covers three scenarios:
cone: both peers behind explicit namespace/veth full-cone emulation, UDP traversal succeedssymmetric: both peers behind symmetric-style NAT, UDP traversal fails, TCP fallback succeedslan: both peers share a LAN subnet, LAN targets are preferred over reflexive addresses
NAT model notes
The harness does not rely on plain Docker MASQUERADE for the cone case.
cone- uses explicit full-cone emulation in the router namespace
- outbound UDP is
SNATed to the router WAN address while preserving the source port - inbound UDP to the router WAN address is
DNATed back to the single LAN host regardless of remote source
symmetric- uses UDP
MASQUERADE --random-fully - outbound mappings may be port-randomized and are only reopened by matching conntrack state
- uses UDP
This distinction matters because plain MASQUERADE is convenient source NAT, but it does not by itself model the "accept from any remote once mapped" behavior expected from a full-cone NAT.
Prerequisites
- Docker with Compose support
- locally built
fips-test:latest
Build the test image with:
./testing/scripts/build.sh
Run
Run all scenarios:
./testing/nat/scripts/nat-test.sh
Run one scenario:
./testing/nat/scripts/nat-test.sh cone
./testing/nat/scripts/nat-test.sh symmetric
./testing/nat/scripts/nat-test.sh lan
Layout
docker-compose.yml- relay/STUN/WAN topology plus container definitions
node/- node bootstrap wrapper that waits for the injected veth interface
router/- NAT router image and
iptablessetup
- NAT router image and
stun/- minimal STUN binding responder
relay/- local
strfryconfig. The relay image's strfry build is pinned by digest indocker-compose.yml(STRFRY_IMAGE); bump it there deliberately.
- local
scripts/generate-configs.sh- derives ephemeral identities and writes per-scenario FIPS configs
scripts/setup-topology.sh- injects and configures the NAT LAN
vethpairs in the container namespaces
- injects and configures the NAT LAN
scripts/nat-test.sh- boots the lab, waits for convergence, and asserts the resulting path
scripts/nostr-relay-test.sh- exercises the Nostr overlay advert publish/consume round-trip, including rejection of a malformed advert event
scripts/stun-faults-test.sh- cycles the daemon through STUN drop, delay and outage faults and asserts graceful behavior at each step
Assertions
-
cone- both nodes connect
- connected transport is UDP
- active link remote addresses are on the WAN NAT subnet
-
symmetric- NAT bootstrap does not establish a UDP link
- fallback converges
- connected transport is TCP via router-published WAN addresses
-
lan- both nodes connect
- connected transport is UDP
- active link remote addresses stay on the shared LAN subnet