fix(dind): open the dind host port on Windows NAT nodes too (#162)

[luthermonson]

Fixes #162.

On a Windows node running the default NAT container network, a job container cannot reach its own dind Docker API. Every Windows docker command times out:

Post "http://10.88.0.1:51064/v1.47/auth": dial tcp 10.88.0.1:51064: i/o timeout

This has blocked build-images.yml's Windows job since ~2026-07-24 — the last successful Windows CI image build was 2026-07-12.

Proven on the live node, not inferred

1. The listener exists. Captured during a real job: dind listening on 10.88.0.1:51098, job container endpoint at 10.88.10.204 (gw 10.88.0.1, /16). So it is a drop, not a closed port — consistent with i/o timeout rather than connection refused.
2. The firewall is the cause. Added one temporary scoped rule (dir=in action=allow protocol=TCP localip=10.88.0.1 remoteip=10.88.0.0/16), re-dispatched build-images.yml, and Login to Docker Hub went green and proceeded to Build and push. The run was then cancelled, the rule deleted, and its absence verified — the node is back to only ephemerd-metrics-9090, with nothing restarted.

That test established a second thing the fix depends on: on the container→gateway path the host firewall matches the container's real 10.88.x.y source. That is what makes per-container scoping viable here, unlike egress, which is SNAT'd (#144's finding).

Not a regression — it never worked on NAT

hostFirewallRules and hyperVEgressRules, removed by #144, contained only block rules — outbound RFC1918 blocks and inbound control-port blocks, zero allows. #144 removed nothing that was serving dind inbound.

openHostPort was born L2Bridge-only in 2bcf222, part of the L2Bridge work. Windows dind-over-TCP arrived in that same effort and the NAT branch was simply never wired up. One bug, always present, invisible until a Windows job actually used Docker — which is why our own release builds pass on that node while docker login does not.

The change, in two halves

Fixing the branch alone would not have worked.

• firewall_windows.go — openHostPort/closeHostPort now resolve through one shared hostPortRuleFor, which picks the host address per path: plan.HostIP on L2Bridge, gatewayForSubnet(cfg.Subnet) on NAT. That derivation is now shared with Manager.GatewayIP() rather than duplicated — two copies that drifted would scope the allow to an address nothing listens on, silently reproducing this exact bug. Routing open and close through one resolver is also what guarantees teardown deletes precisely what setup added.
• network_windows.go — SetupResult.IP was empty on NAT, because ephemerd only pins addresses on L2Bridge and HNS allocates on NAT. setup() now reads the address back off the created HCN endpoint, with fallbacks by ID then by name.

Scoping

The /32 per-container scoping from #152 is preserved and extended to NAT, which needs it just as much: all job containers share 10.88.0.0/16 and can address the gateway, so a subnet-wide allow would let one job scan the gateway's ephemeral range and drive another job's unauthenticated Docker daemon. Malformed or missing addresses still fail closed.

hostPortRulePrefix deliberately keeps its -l2b- token: it is the only handle the shutdown sweep has on allows leaked by a previously running build, so renaming it would strand them.

Tests

Six new tests in hostport_windows_test.go plus one in networking_test.go, verified to fail against the pre-fix behaviour by temporarily restoring the early return:

--- FAIL: TestHostPortRuleFor_NATOpensAScopedAllow
    NAT path installed no host-port allow — this is #162 ...
--- FAIL: TestHostPortRuleFor_NATNeverScopedToTheSubnet
--- FAIL: TestHostPortLocalIP_NATTracksTheConfiguredSubnet
--- FAIL: TestHostPortRuleFor_TeardownTargetsExactlyWhatSetupAdded
--- FAIL: TestHostPortRuleFor_NATFailsClosed

TestHostPortRuleFor_L2BridgeUnchanged stayed green in both states, confirming the L2Bridge path is untouched.

GOOS=windows go build ./..., GOOS=linux go build ./..., both go vets, and the full go test ./... are clean. (GOOS=darwin go build fails in Code-Hex/vz for want of cgo + the macOS SDK — pre-existing.)

Behaviour change worth weighing

With SetupResult.IP now load-bearing on NAT, a Windows job whose endpoint address cannot be read will fail to provision rather than starting and silently losing Docker. That matches the codebase's fail-closed posture, and the address comes straight from HNS with two fallbacks — but it is a new way a Windows job can fail.

Verifying after deploy

1. Dispatch build-images.yml; the Windows Login to Docker Hub step should pass.
2. During a job: Get-NetFirewallRule -DisplayName 'ephemerd-egress-l2b-hostport-*' shows exactly one rule per running job, with RemoteAddress = the container's single address (not 10.88.0.0/16) and LocalPort = the dind port.
3. After the job the rule is gone; after a daemon restart none survive (prefix sweep).