diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index ce29098..83f9145 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -57,9 +57,12 @@ is a queued finding), plus a temporary `192.168.1.2/22` to reach the factory LAN. **D-125 egress gate EXECUTED 2026-07-20 (as written, throwaway VM) -- PARTIAL, gate OPEN**: bridge-in PROVEN (foreign MAC in - vvr1-dc0 -> vcloud ISP NAT gateway, ping 3/3) but upstream egress FAILS - for both ICMP and TCP; controls pass (vcloud egress OK; office1 edge - egresses via the same-shape office1-wan NAT). Config/design ruled out by + vvr1-dc0 -> vcloud ISP NAT gateway, ping 3/3) but the guest's upstream + egress FAILS (ICMP; a TCP datapoint from the GUEST is still missing -- + the rack-sourced follow-up was confounded by the rack having no default + route, corrected in the changelog per C2). Controls pass (vcloud egress + OK; office1 edge egresses via the same-shape office1-wan NAT). + Config/design ruled out by `net-dumpxml` equivalence, so the suspect is vcloud's live firewall rules for virbr4; the double-NAT fallback is NOT invoked (it remedies a design failure, not a host rule gap). Blocked on one read-only diff --git a/docs/changelog-20260719-dc0-deploy-stepB.md b/docs/changelog-20260719-dc0-deploy-stepB.md index 8fb7a20..294fd98 100644 --- a/docs/changelog-20260719-dc0-deploy-stepB.md +++ b/docs/changelog-20260719-dc0-deploy-stepB.md @@ -289,9 +289,18 @@ **gateway ping 3/3, 0% loss** -- a FOREIGN MAC inside vvr1-dc0 reaches the vcloud ISP NAT across the nested bridge. That is the D-125 bridge-in property, and it PASSES. But `ping 1.1.1.1` FAILED (NET-PING-RC=1). -- Follow-up measurement (rack bridge, 172.30.2.51, self-cleaning): ICMP - AND TCP (`curl http://1.1.1.1` -> 000) both fail past the gateway, so it - is not ICMP-specific. Controls: vcloud egress 0% loss; the office1 edge +- **CORRECTION (2026-07-20, same-day): the rack-bridge follow-up is + CONFOUNDED and is NOT evidence.** It sourced from 172.30.2.51 on the + rack, but the rack has NO DEFAULT ROUTE (netplan gives it only + `10.10.0.0/22 via 172.31.0.1`; the WAN bridge is IP-less by design), so + traffic to 1.1.1.1 fails in the rack's own routing table before the NAT + is ever consulted. Its ICMP+TCP failures say nothing about virbr4. The + ONLY clean signal is the GUEST's (172.30.2.50) failed egress, and that + guest tested ICMP only -- if the rule dump comes back identical for both + bridges, re-run the guest probe with `curl` before concluding anything. + (Recorded per GA-R1/C2: a wrong measurement is corrected in the record, + not quietly dropped.) +- Controls: vcloud egress 0% loss; the office1 edge egresses through the SAME-SHAPE `office1-wan` NAT 0% loss. The two network definitions are byte-equivalent in substance (`net-dumpxml`: both `forward mode=nat` + ``; only netmask-vs- @@ -301,9 +310,17 @@ double-NAT) is for a DESIGN failure; invoking it against what is very likely a host firewall-rule gap would be the wrong remedy and would add Roosevelt delta. Next step is a read-only measurement needing operator - sudo: `sudo nft list ruleset | grep -nE "172\.30\.(1|2)\.0/24"` (or - `sudo iptables -t nat -S | grep 172.30`) comparing the WORKING virbr11 - rules against virbr4's. + sudo: FULL dumps of BOTH `nft list ruleset` and `iptables-save` (which + backend is authoritative here is itself unmeasured -- do not assume), + diffing virbr4 against the WORKING virbr11. Two rule families must both + be checked, and a subnet-only grep would MISS the second: POSTROUTING + masquerade (keyed on `172.30.2.0/24`) and FORWARD accept (keyed on the + INTERFACE `virbr4`). Pre-staged fix-forward IF the rules are absent or + malformed vs virbr11: `virsh net-destroy vr1-dc0-uplink && virsh + net-start vr1-dc0-uplink` reinstalls libvirt's rules from scratch -- + cheap and safe (nothing rides that uplink yet but the probe). If instead + the dump shows libvirt never installed them correctly, the restart will + not help and the dig moves to the firewall backend / conntrack. - **Revert:** nothing to revert -- the probe guest and both temporary addresses were removed; the only residue is `/tmp/noble.img` on the rack (kept deliberately: it is the base for any future throwaway probe).