mirror of https://github.com/jmcorgan/fips.git synced 2026-10-05 19:18:25 +00:00

Files

T

History

Johnathan Corgan 1cc069f1a2 Gather the host-side IPv6 plane into the ipv6tun module

The TUN adapter, the .fips DNS responder, ICMPv6 generation and TCP MSS
clamping are the host-side IPv6 plane, but the code was split between
src/upper and inline bodies in the node's session handler and lifecycle.
Gather it into one module, src/ipv6tun, and reduce its calls into the
rest of the crate to a small explicit set. This prepares the TUN adapter
to run later as a separate daemon over the native API, and gives
embedders one place to find the host-side surface. Behaviour is
unchanged apart from log target names.

- Rename src/upper to src/ipv6tun. A `pub use ipv6tun as upper;` alias
  keeps every crate::upper:: and fips::upper:: path resolving, so no
  consumer has to change.
- Move hosts.rs whole to src/hosts.rs, a top-level public module: the
  hosts file also serves peer display names, the peer ACL and fipsctl,
  so it is not host-side only. ipv6tun re-exports it for the old path.
- Move the DNS socket helpers (dual-stack bind, IPV6_RECVPKTINFO,
  interface index lookup) from Node into ipv6tun::dns, unchanged.
  Node::mesh_ifindex, which reads the live TUN device name, becomes
  Handles::mesh_ifindex.
- Move ICMPv6 Destination Unreachable and Packet Too Big sending into
  ipv6tun::icmp behind IcmpContext, which borrows the TUN channel, our
  address and the Packet Too Big rate limiter for one use. Packet Too
  Big is still rate limited and Destination Unreachable still is not.
  The discovery lookup timeout hands its queued packets over as one
  no-route report.
- Split handle_tun_outbound. The host-side half, in ipv6tun::outbound,
  validates the packet, makes both Packet Too Big decisions and sends
  the ICMPv6 replies, reaching the mesh through a small Mesh trait Node
  implements. The mesh-side half, Node::send_outbound, stays with the
  pending queue. The checks run in the same order with the same
  thresholds, and Node::handle_tun_outbound remains the entry point.
- Move the TUN and DNS child start and stop bodies into
  ipv6tun::lifecycle, and gather their nine supervisor fields and the
  node's TUN device name into one Handles struct the supervisor holds.
  The supervisor arms, their order and the child-exit reporting are
  unchanged. A TUN still counts as up when it has a device
  name, so an app-owned TUN produces no TUN teardown, and DNS counts as
  up while its task runs. The node passes a new peer-alias base to the
  running responder through Handles::publish_aliases. Node::tun_name,
  tun_tx, dns_local_addr and enable_app_owned_tun keep their behaviour;
  tests install a TUN sender through a test-only Node::install_tun.

Tracing targets follow module paths, so lines from the moved code now
log under fips::ipv6tun::* and fips::hosts instead of fips::upper::*,
fips::node::lifecycle and fips::node::handlers::session. Update the
RUST_LOG example in the MTU diagnosis guide and the test harness
filters that relied on the old targets, and note the rename in the
changelog.

2026-10-05 16:27:45 +00:00

.gitignore

Let the acl-allowlist suite float its docker subnet

2026-07-25 19:01:16 +00:00

docker-compose.yml

Gather the host-side IPv6 plane into the ipv6tun module

2026-10-05 16:27:45 +00:00

generate-configs.sh

Let the acl-allowlist suite float its docker subnet

2026-07-25 19:01:16 +00:00

README.md

Gather the host-side IPv6 plane into the ipv6tun module

2026-10-05 16:27:45 +00:00

test.sh

Stop the firewall and ACL suites building or pulling the test image when the harness supplies it

2026-09-19 00:42:35 +00:00

README.md

ACL Allowlist Test

Six Docker nodes use per-node ACL files mounted at the hardcoded runtime paths:

node-a and node-b carry the insider allowlist (node-a, node-b, node-e, node-f)
node-c and node-d each carry a broad allowlist containing every node alias
node-e and node-f do not mount any ACL files locally
every node gets a generated /etc/fips/hosts with aliases for node-a through node-f

This lets us test three different node behaviors at once:

insiders (a, b) explicitly allow a, b, e, and f
outsiders (c, d) allow everyone locally, but still cannot join because insiders reject them
allowed remotes (e, f) rely on the insider ACLs and do not need local ACL files

Test Identities

Allowed:

node-a
- npub1sjlh2c3x9w7kjsqg2ay080n2lff2uvt325vpan33ke34rn8l5jcqawh57m
- 0102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f20
node-b
- npub1tdwa4vjrjl33pcjdpf2t4p027nl86xrx24g4d3avg4vwvayr3g8qhd84le
- b102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fb0

Denied:

node-c
- npub1cld9yay0u24davpu6c35l4vldrhzvaq66pcqtg9a0j2cnjrn9rtsxx2pe6
- c102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fc0
node-d
- npub1n9lpnv0592cc2ps6nm0ca3qls642vx7yjsv35rkxqzj2vgds52sqgpverl
- d102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fd0

Additional allowed:

node-e
- npub1x5z9rwzzm26q9verutx4aajhf2zw2pyp34c6whhde2zduxqav40qgq36l6
- nsec1egyrmekfw3u4l88v8zhrak9uht503s2kvn9v49tqgp6c5l2yuxgsv386l0
node-f
- npub1ytrut7gjncn2zfnhn56c0zgftf0w6p99gf6fu8j73hzw5603zglqc9av6c
- nsec1afh3nysthqh47awpdewcw59wvvp499f8dvlyclmnv4gvpxdk56dsa6eqsn

The generated fips.key fixtures use a mix of bare hex and nsec1... values. FIPS accepts either format in key files.

Run

Build the Linux binaries and test image:

./testing/scripts/build.sh --no-docker

Start the ACL test mesh:

./testing/acl-allowlist/generate-configs.sh
docker compose -f testing/acl-allowlist/docker-compose.yml up -d --build

Or run the full integration check:

./testing/acl-allowlist/test.sh

test.sh regenerates the ACL fixtures automatically before starting Docker. The generated ACL files use alias names, and the generated hosts file makes those aliases resolvable at runtime.

The ACL harness pins the expected test entrypoint explicitly so it does not accidentally reuse an older fips-test:latest image with a different startup script.

Docker service/container/hostname identifiers in this harness intentionally use service-*, fips-acl-container-*, and host-* names so they do not collide with the logical FIPS aliases node-a through node-f. For data-plane checks and operator examples, use the explicit FIPS names such as node-a.fips and node-d.fips.

The bridge network requests no subnet, so docker assigns one from its own address pool and two concurrent runs of this harness never contend for a fixed range. Consequently no node's IPv4 address is known before startup, and the generated peer stanzas address each other by docker hostname (host-a … host-f), resolved through the container's dnsmasq to docker's embedded DNS.

ACL paths are fixed in this branch:

/etc/fips/peers.allow
/etc/fips/peers.deny

Mounted ACL files in this harness:

node-a and node-b: insider allowlist plus ALL deny fallback
node-c and node-d: broad local allowlist used by outsider nodes trying to blend in
node-e and node-f: no ACL files mounted
all nodes: /etc/fips/hosts aliases for node-a through node-f

Generated fixture location:

testing/acl-allowlist/generated-configs/, or generated-configs<suffix>/ when FIPS_CI_NAME_SUFFIX is set, which is how concurrent runs keep their fixtures apart

Inspect peer state:

docker exec fips-acl-container-a fipsctl show peers
docker exec fips-acl-container-b fipsctl show peers
docker exec fips-acl-container-c fipsctl show peers
docker exec fips-acl-container-d fipsctl show peers
docker exec fips-acl-container-e fipsctl show peers
docker exec fips-acl-container-f fipsctl show peers

Inspect the loaded ACL state directly:

docker exec fips-acl-container-a fipsctl acl show

Use explicit .fips names when checking reachability through the FIPS overlay:

docker exec fips-acl-container-a ping node-d.fips
docker exec fips-acl-container-a ping npub1n9lpnv0592cc2ps6nm0ca3qls642vx7yjsv35rkxqzj2vgds52sqgpverl.fips

The output shows both the original ACL file entries and the resolved effective npub entries.

Expected:

node-a sees node-b, node-e, and node-f
node-b sees node-a
node-c sees no peers
node-d sees no peers
node-e sees node-a
node-f sees node-a

Visible rejection logs:

docker compose -f testing/acl-allowlist/docker-compose.yml logs -f service-a service-b service-c service-d service-e service-f

On startup, node-c and node-d immediately try their configured outbound static connection to node-a. Their own ACLs permit that attempt, but the insider ACL on node-a still rejects both peers. Because node-a also has static peer stanzas for node-c and node-d, you may see both outbound_connect and inbound_handshake rejection messages during startup. The outsider-initiated path emits messages like:

Rejected peer by ACL ... context=inbound_handshake decision=denylist match

Those messages are now emitted at debug level. This harness enables fips::node=debug in RUST_LOG so the ACL rejection details stay visible in test logs, and operators can temporarily raise log level the same way when diagnosing ACL issues locally.

A later ping6 from node-c.fips does not emit a new inbound_handshake message. The ping uses the data-plane session path, and since no peer session to node-a.fips was established, it just times out.

Stop and clean up:

docker compose -f testing/acl-allowlist/docker-compose.yml down