mirror of
https://github.com/jmcorgan/fips.git
synced 2026-10-05 19:18:25 +00:00
Johnathan Corgan
242e619169
Two unrelated harness defects with the same shape: the run's verdict names something other than what actually went wrong. The nostr publish/consume suite treats a dead relay as a product failure. strfry is a third-party container and it has segfaulted mid-run, twelve milliseconds after both nodes connected; everything below that was a correct report of a dead relay, and the run failed on the peer-count wait with the only evidence of the real cause sitting in one container-log line ninety lines above the summary. Add a relay verdict that states the relay's own condition — gone, not running, restarted, or faulted per its log — and print it at the head of every diagnostics dump, which is what every failure path already goes through. A relay whose state or log cannot be read is reported as unestablished rather than as healthy. The verdict does not decide the run: a relay that faulted while the assertions still passed is noted and left passing, since the suite proved what it set out to prove. The setup-bucket refill test raced its own precondition. It delivered exactly three forged setups against a 50/s refill and asserted one had been refused, which holds only if all three finish inside one 20 ms window; on a loaded runner the bucket refilled mid-loop, the third setup was admitted, and the precondition failed on arrangement rather than on behaviour. Under the CI retry policy that reports as green with a flaky count, so nothing surfaced it. Drain against a 2/s refill, which a delivery would have to take 500 ms to outrun, and deliver until a refusal is actually observed rather than assuming three is enough, with a cap that says what a runner slow enough to reach it means. The refill half then waits out a full burst from empty. (cherry picked from commit ec0fadfd136e0f6a64551fab61d042e486861842)
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
- 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
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