Johnathan Corgan
9668807ca4
Tailscale-style sidecar pattern: a FIPS container provides mesh networking, and a companion app container shares its network namespace via network_mode: service:fips. Security model: - iptables enforces strict isolation — the app container can only communicate over the FIPS mesh (fd::/8 via fips0) - No IPv4 access: eth0 restricted to FIPS UDP transport (port 2121) - No IPv6 on eth0: ip6tables blocks all eth0 IPv6 traffic - Only fips0 and loopback are reachable from the app container The sidecar accepts peer configuration via environment variables (FIPS_NSEC, FIPS_PEER_NPUB, FIPS_PEER_ADDR), so it can be pointed at any FIPS node without config file generation. Files: - testing/sidecar/: Dockerfile, Dockerfile.app, docker-compose.yml, entrypoint.sh, .env, resolv.conf, scripts/build.sh - testing/sidecar/README.md: security model, quick-start, architecture, DNS resolution, troubleshooting, production considerations - testing/sidecar/scripts/test-sidecar.sh: 3-node chain integration test verifying link establishment, multi-hop connectivity, and network isolation on each app container - .github/workflows/ci.yml: sidecar integration test matrix entry
FIPS Testing
Integration and simulation test harnesses for FIPS, using Docker containers running the full protocol stack.
Test Harnesses
static/ -- Static Docker Network
Fixed topologies with manual scripts for building, config generation, connectivity tests (ping, iperf), and network impairment (netem). Useful for deterministic debugging and validating specific topology configurations.
| Topology | Nodes | Transport | Description |
|---|---|---|---|
| mesh | 5 | UDP | Sparse mesh, 6 links, multi-hop |
| chain | 5 | UDP | Linear chain, max 4-hop paths |
| mesh-public | 5+1 | UDP | Mesh with external public node |
| tcp-chain | 3 | TCP | Linear chain over TCP (port 443) |
chaos/ -- Stochastic Simulation
Automated network testing with configurable node counts, topology algorithms (random geometric, Erdos-Renyi, chain, explicit), and fault injection (netem mutation, link flaps, traffic generation, node churn). 16 scenarios covering general stress testing, cost-based parent selection, mixed link technologies (fiber/Bluetooth/WiFi), and transport-specific validation (UDP, TCP, Ethernet). Scenarios are defined in YAML and executed via a Python harness that manages the full lifecycle: topology generation, Docker orchestration, fault scheduling, log collection, and analysis.