fix(pep): resolve a named endpoint over a bound socket

[bojieli]

What was wrong

--local-address exists so the outer path bypasses a host TUN route, and netbind.InterfaceControl asserts that at the kernel level with IP_BOUND_IF — which is what makes NEAppProxyFlow.isBound true, so a transparent proxy honouring it leaves those sockets alone.

That covers the sockets this client creates. It did not cover the ones the resolver creates on its behalf. net.Dialer applies LocalAddr and Control to the connection it dials, never to the lookup that turns the endpoint name into the address it dials to — and dialQUICConnection used net.ResolveUDPAddr, which is the default resolver outright.

So a client bound to a physical interface still asked that one question over an unbound socket.

Why it is fatal rather than untidy

On a host whose transparent proxy redirects port 53, that unbound question is claimed and sent to the proxy — which, when this client is the proxy's upstream, is this client. The name has to resolve before the datapath exists, and the datapath has to exist before the name resolves.

Observed on a live host: a provider whose endpoint is <name>:12540 logged lookup <name>: no such host on both transports 25,365 times in 67 minutes and never came up. Its lane sockets were fine the whole time — 20,162 of them went out direct under bypass:bound-interface, exactly as designed. Only the lookup leaked.

The fix

netbind.ResolverFor(spec, control) returns a resolver whose own sockets carry the same interface binding and source address as a data socket built for spec. Both lane paths use it for the endpoint name: the TCP dialer via net.Dialer.Resolver, and the QUIC path via a new resolveUDPAddrBound.

Two deliberate limits:

• PreferGo is required or the cgo resolver answers inside libSystem and never calls Dial, silently dropping the binding. That has a cost — the pure resolver reads /etc/resolv.conf rather than the platform's own configuration — which is why the scope is the endpoint lookup rather than a process-wide resolver. A gateway endpoint is a public name reached over a specific interface, the lookup least likely to want split-horizon rules.
• A source address is bound only when its family matches the nameserver's, since a mismatched one cannot carry the query. The interface binding still applies, and that is the part capture reads.

A literal endpoint address needs no lookup and takes the same path it always did.

Tests

New: internal/netbind/resolver_test.go (default resolver when unbound, error propagation, the dial actually leaving from the bound address, and family matching); internal/pep/resolve_test.go (literal fast path for v4 and v6, malformed endpoint, and an unusable local address surfacing as itself rather than as a lookup failure).

go vet and staticcheck -checks=all,-U1000 clean on both packages.

Note: go test -short -race ./... locally times out in internal/fec on TestTheWindowRateIsWhatTheWindowNeeds (~10m under the race detector). That is pre-existing and unreachable from these packages — go list -deps ./internal/fec contains neither netbind nor pep — and is not the combination CI runs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MHr1RSawjHAuUBJwK63vxE