atenet: bind the Envoy sockets and Services dual-stack

[Yuan Gao (ygao-g)]

Fixes #910
Part of #246

It's a good idea to open an issue first for discussion.

• Tests pass
• Appropriate changes to documentation are included in the PR (none needed — no flags, APIs, or user-facing behaviour change)

---

Every Envoy socket in atenet binds the IPv4 wildcard, and neither gateway's Service asks for a second IP family. On a dual-stack cluster the router answers on its IPv4 ClusterIP and on nothing at all for IPv6. On an IPv6-primary cluster it is worse than a dark data path: the kubelet probes the pod on its only address, so atenet-egress crashloops while Envoy itself starts fine.

Both gateways now bind :: as well, and both Services ask for PreferDualStack. Where the config takes more than one address — the two ingress Listeners — the 0.0.0.0 primary is left untouched and :: is added alongside it. Where it takes only one — the two Envoy admin sockets, whose bootstrap field is singular, and the egress :443 Listener — the socket binds :: with ipv4_compat. That flag is load-bearing, not decoration: the router's dataplane health check dials 127.0.0.1:9901 and the egress drainer dials 127.0.0.1:15000, and a refused drain is reported as a completed one. A new hack/verify check keeps it that way, since nothing else in the tree reads these manifests.

This makes both gateways accept IPv6; it does not make them reach IPv6 destinations. The egress dns_lookup_family, the DNS AAAA path, and atunnel's original-destination lookup stay IPv4 and are tracked in #246 and #686.

Testing

CI has no IP-family matrix, so the green e2e run here is the IPv4 regression check and nothing more. The other two families were verified by hand on kind, using the IP_FAMILY support from #877.

• go test ./cmd/atenet/internal/router/... — asserts the 0.0.0.0 primary, exactly one :: additional address, ipv4_compat false, and the port, on both ingress listeners.
• Dual-stack. Both Services come up with two ClusterIPs and both gateway pods run with 0 restarts. The networking suite passes with zero skips: an actor is reached over each of the router's ClusterIPs, and an IPv4 actor transits the egress [::]:443 socket. Reverting only the two bind lines turns those assertions red, so they are not passing vacuously. ipv4_compat was read from /config_dump — /listeners reports resolved bound addresses and never emits the flag.
• IPv6-only, with the kind CoreDNS fix from hack: fix DNS on IPv6-only kind clusters #958 underneath. atenet-egress goes from 1/2 CrashLoopBackOff (64 restarts, startup probe refused) to 2/2 Running, Envoy logs admin address: [::]:15000, and both 127.0.0.1:15000/ready and [::1]:15000/ready return 200. TestActorDirectAccess passes, including through the router's ingress. TestActorEgress still fails, but inside the actor's netns, which is ateomnet: enable IPv6 forwarding in worker pod netns #979's scope.

A node with no AF_INET6 at all could not bind :: and the listener would not come up; every node image we target has it, and the IPv4 e2e above is the check.

🤖 Generated with Claude Code

[Yuan Gao (ygao-g)]

Bowei Du (@bowei) mind taking a look?

[Bowei Du (bowei)]

Do we want to sync up the configuration in the YAML with the configuration here?

[Bowei Du (bowei)]

Actually, the comment here might have confused me. This is talking about two different sockets? If it is, can you remove the comment above.

[Yuan Gao (ygao-g)]

Yes, two different sockets. This is the router's ingress data-plane listener; the ipv4_compat: true you saw in the YAML is the Envoy admin socket on 9901. I've cut the comment down to the one line explaining why Ipv4Compat is false here — the cross-reference to the admin socket was the confusing part and it's gone.

On the original question: the admin sockets can't take this shape anyway, since bootstrap.v3.Admin has a single address field and no additional_addresses — one :: socket with ipv4_compat is the only way to serve both families there. The egress :443 listener is a real Listener, so that one could match the ingress shape if you'd rather have a single idiom across listeners. Happy to do it; it's a few lines plus the test that asserts the current shape.