laantungir/fips
1
0
Fork 0
mirror of https://github.com/jmcorgan/fips.git synced 2026-10-06 03:28:24 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
056f577ad36618a81b1b97270e28be7b9496ec27
fips/testing/nat
T
History
Johnathan Corgan fe9e51316f Merge branch 'master' into next 
Five conflicts, all from the pre-v0.5.0 batch landing in handshake and
rekey code that next's peer/control-machine refactor has already
rewritten. How each was resolved, since none of it is mechanical:

src/node/handlers/rekey.rs keeps next's comment. Both sides describe the
same removal and differ only in which sibling arms they name, and next's
names next's own.

src/node/handlers/handshake.rs takes master's comment. next already had
the `let _slot` binding and the test-build assertion below it; what it
lacked was the paragraph saying why the binding name is load-bearing,
which is the thing a later tidy-up would delete.

src/node/tests/acl.rs keeps next's file whole. next already covers the
outbound ACL reject arm with a test written against its own structure;
master's variant is written against master's API and its helper does not
exist here. An earlier attempt spliced the two and produced a duplicate
definition and four unresolved names.

src/node/tests/unit.rs keeps next's side plus one test from master's,
`msg1_handler_holds_its_pending_slot_while_the_handler_runs`. The rest of
master's side already exists on next and would have duplicated it. The
test is placed at module level: the conflict boundary fell inside another
function's signature, so taking the hunk verbatim nested it and clippy
caught it as an inner test item.

src/node/tests/establish_chartests.rs is removed. next has no such
module; master modified it in the same commit.

Gated here rather than assumed: rustfmt clean, clippy clean at
-D warnings, 2381 tests passed and 0 failed, all six repo guards exit 0,
and the carried-over test confirmed present in the run output.
2026-08-25 21:27:37 +01:00
..
node
Add Nostr-mediated overlay discovery and UDP NAT traversal (#53)
2026-04-27 08:15:58 -07:00
relay
Add Nostr-mediated overlay discovery and UDP NAT traversal (#53)
2026-04-27 08:15:58 -07:00
router
Add Nostr-mediated overlay discovery and UDP NAT traversal (#53)
2026-04-27 08:15:58 -07:00
scripts
Merge branch 'master' into next
2026-08-25 21:27:37 +01:00
stun
Add Nostr-mediated overlay discovery and UDP NAT traversal (#53)
2026-04-27 08:15:58 -07:00
.gitignore
Give the NAT lab per-run generated configs
2026-07-27 14:34:33 +00:00
docker-compose.external-net.yml
Claim the NAT lab's two bridges per run and derive every address from them
2026-07-27 14:34:46 +00:00
docker-compose.yml
Merge branch 'maint'
2026-07-27 17:57:21 +00:00
README.md
Add Nostr-mediated overlay discovery and UDP NAT traversal (#53)
2026-04-27 08:15:58 -07:00

README.md

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

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
Reference in New Issue View Git Blame Copy Permalink