The loopback hairpin Docker test greps for the rule but never checks the MASQUERADE target

[FAZuH]

Found while closing #51. The same weakness #51 was about, on the hairpin rule rather than the port mapping rule.

The gap

docker_mapping_loopback_host_installs_loopback_masquerade in tests/natmap_docker.rs greps iptables-save for:

-s 127.0.0.0/8 -d 172.18.0.2

and asserts that output exists. It never checks the jump target. So changing the hairpin MASQUERADE to any other target leaves the test green, even though the rule no longer masquerades and the hairpin stops working.

This is the identical weakness #51 filed for the port mapping rule, and the same experiment exposes it: mutate build_masquerade_args in crates/natmap/src/iptables.rs:184 from MASQUERADE to ACCEPT and the test passes unchanged.

Why it matters

Per CONTEXT.md, hairpin is "the ability to reach a forwarded service through its external address from inside the LAN. Requires a MASQUERADE so the reply leaves via the LAN gateway." The MASQUERADE is the whole mechanism, and a test that greps for the rule's match fields without checking the target does not verify it. The port mapping counterpart of this test now does check the target, because #51 added a full-set assertion for that path.

What to build

Extend the loopback hairpin test to assert the jump target, not just the match. The negative counterpart (..._rejects_... or similar) should confirm the rule is absent when hairpin is off.

Consider whether asserting the whole hairpin rule set with one assert_eq! on a sorted Vec<&str>, as #51 does for the port mapping path, is better than widening the existing grep. It gives a readable failure that names the exact rule and the exact difference, which a contains cannot.

Acceptance criteria

• Mutating the hairpin MASQUERADE jump target makes a Docker test fail. Demonstrate it, as The Docker suite does not cover the MASQUERADE rule it is named for #51 did.
• The negative case confirms absence, not just a failed grep
• cargo test -p lab-ops --all-features --test natmap_docker passes
• crates/natmap/src/iptables.rs is unchanged; this is a test fix only

[FAZuH]

Landed on v0.2 as 3c983b2, merged 3b4f056. Closed by hand: a closing keyword only fires from commits reaching the default branch.

The ticket's own pointer was wrong, and the correction is the point

It named crates/natmap/src/iptables.rs:184, which is build_masquerade_args — the port-mapping rule #51's test already owns. Mutating it does not touch hairpin. The hairpin jump target is line 246, in build_loopback_masq_args. Both lines read "MASQUERADE".into(),, which is exactly how a plausible pointer lands on the wrong builder.

The criterion, met

Mutating line 246 to ACCEPT:

test natmap_docker::docker_mapping_loopback_host_installs_loopback_masquerade ... FAILED
assertion \`left == right\` failed: loopback→container MASQUERADE rule does not match:
  left: [... "-j ACCEPT"]
 right: [... "-j MASQUERADE"]
test result: FAILED. 3 passed; 1 failed          (loadavg 3.76/1.63/1.37)

docker_mapping_remove_cleans_up_loopback_masquerade and #51's test both stayed green under that mutation, which is the proof the old grep was target-blind. iptables.rs is byte-identical to HEAD afterwards.

The negative test was not weak, it was vacuous

It read grep -q ... && (echo FAIL >&2 && exit 1) || echo 'PASS'. The exit 1 is inside a subshell, so it kills the subshell, || echo 'PASS' fires, the script exits 0:

$ sh -c 'false && (echo "FAIL-branch" >&2; exit 1) || echo PASS; echo "final=$?"'
PASS
final=0

A rule that was installed — the exact case the test exists to catch — exited 0 and reported success. It now uses a control grep plus a top-level if … exit 1, so run_in_docker panics with the rule set on stderr. The absence check was also satisfiable by a broken environment: a missing iptables yields empty input, grep exits 1, and the rule reads as "absent". The control grep now fails first. Both paths verified by hand in a privileged container.

Targeted rather than a second full set

#51's test owns the complete rule set for an ordinary mapping, and 2 of the loopback mapping's 5 rules are byte-identical to it. A second full set would re-prove those and add nothing to this criterion. The targeted form still asserts the entire hairpin rule. A full-set assertion for the loopback mapping would also cover the two -d 127.0.0.1/32 rules nothing checks — noted, not done.

Verification

natmap_docker: 35 passed, 0 failed, exit 0, loadavg 4.89/4.57. format and lint clean. Full suite 427 passed, 0 failed, 10 targets, exit 0.

The bigger finding, filed separately

The same && (echo … && exit 1) || echo 'PASS' shape is at 18 sites in tests/natmap_docker.rs, and in every one the failure branch is a no-op. See the new issue.