Files
fips/testing/nat
Johnathan Corgan 4c345f3ffd Make the malformed-advert phase inject the stimulus it asserts against
Two test helpers piped a heredoc into `docker exec <container> python3 -`
with no `-i`. Without it docker attaches no stdin, so `python3 -` reads an
empty program, runs nothing and exits 0; `set -euo pipefail` cannot catch a
success. Measured on this host at docker 29.1.3 against a live container:
without the flag the program produced no output and returned 0, with it the
program ran.

The relay half is the serious one. The publisher it silently skipped is the
malformed Kind-37195 event that phase 3 exists to inject, and the three
assertions that follow hold whether or not anything was injected, so the
phase has passed in all 51 archived runs without exercising the path it
covers. The NAT half only makes a diagnostic vacuous, but it did real
damage once: every tcpdump wrapped around the STUN probe reported 0 packets
captured, and that was read as a packet leaving the node and vanishing.

Adding `-i` alone is not enough. The publisher printed its completion line
unconditionally, after reading the relay's reply and discarding it, so a
refused event would still have satisfied a check that only looked for that
line. strfry verifies the event id and the signature and answers
["OK",<id>,false,"invalid: ..."] on refusal, and a refused event is never
stored and never broadcast. The publisher now parses the relay's verdict and
exits non-zero on anything but an acceptance, and phase 3 reds unless the
relay reports the event stored.

The verdict is read by decoding the websocket frame rather than by matching
a substring. NIP-01's OK is a four-element array whose message is mandatory
even on success, so `,true]` never occurs in a conformant acceptance; and a
91-byte payload puts a literal '[' in the frame's length byte, so searching
for the JSON finds the header. Both were found by testing the guard against
frames built the way a relay builds them.

Three comments are corrected while here. The publisher's header claimed the
daemons log a parse error and that the content fails to deserialize; neither
holds, because the `protocol` tag is checked first and the discard emits no
diagnostic. The kind and `d` tag are now documented as duplicating the
consumers' subscription filter, which is what makes them able to drift.

Expect phase 3 to exercise the missing-protocol-tag branch for the first
time. A red there is a finding rather than a regression this introduces.
2026-09-07 17:12:39 +00:00
..
2026-07-27 17:57:21 +00:00
2026-08-30 10:42:59 +00:00

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 succeeds
  • symmetric: both peers behind symmetric-style NAT, UDP traversal fails, TCP fallback succeeds
  • lan: 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

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 iptables setup
  • stun/
    • minimal STUN binding responder
  • relay/
    • local strfry config
  • scripts/generate-configs.sh
    • derives ephemeral identities and writes per-scenario FIPS configs
  • scripts/setup-topology.sh
    • injects and configures the NAT LAN veth pairs in the container namespaces
  • 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