test(e2e): docker multi-container gateway e2e for the real forward path#47
Merged
Conversation
…d path The loopback e2e runs the proxy and test servers on one host via the firewall's OUTPUT/redirect path with --local-traffic. That structurally cannot exercise the real gateway forwarding path — PREROUTING redirect, FORWARD drop, and UDP TPROXY — so the entire SOCKS5 UDP ASSOCIATE QUIC relay (src/udp.rs) had zero e2e coverage. Add a docker-compose topology (docker/gateway-e2e.yml) where a client container routes its WAN traffic through a trans_proxy "gateway" container to a WAN server container, driven by scripts/docker_gateway_e2e.sh across two scenarios: * SOCKS5 upstream → TCP proxied, UDP/QUIC relayed (echo returns). * HTTP CONNECT upstream → TCP proxied, UDP/QUIC dropped (no echo). Supporting changes: - test_servers: SOCKS5 server now handles UDP ASSOCIATE (RFC 1928 §7 encap/decap relay); new UDP echo destination; all servers take a configurable bind address + optional fixed ports via env (defaults preserve the loopback e2e). fwmark gains a generic SO_MARK helper. - e2e: new gw_client bin (the LAN-side driver: asserts TCP body + UDP relay/drop); TestServerPorts gains udp_echo_port. - CI: new "E2E Gateway (Docker)" job; CLAUDE.md documents the topology. Verified locally: both docker scenarios pass (UDP relay echo confirmed end-to-end through the gateway), the existing loopback e2e still passes 5/5 in a privileged container, and fmt/clippy/test are clean on macOS with a -D warnings Linux cross-build. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation (audit finding)
The existing e2e runs the proxy + test servers on one host over loopback, via the firewall's OUTPUT/redirect path with
--local-traffic. That model structurally cannot exercise the real gateway forwarding path — PREROUTING redirect, FORWARD drop, and UDP TPROXY. As a result the entire SOCKS5 UDP ASSOCIATE QUIC relay (src/udp.rs, added in #46) had zero e2e coverage — its in-code comment even said the TPROXY path "needs a real forwarding/ingress setup and is covered separately."This PR adds that setup.
What's added
A docker-compose topology (
docker/gateway-e2e.yml) with real L3 routing:gw_clientdriver.trans_proxywith a real PREROUTING redirect (TCP) + TPROXY (UDP).scripts/docker_gateway_e2e.shruns it across two scenarios:Supporting changes
fwmarkgains a genericSO_MARKhelper.gw_clientbin (LAN-side driver — asserts the TCP body and the UDP relay/drop);TestServerPortsgainsudp_echo_port.E2E Gateway (Docker)job.CLAUDE.mddocuments the topology.Verification (local)
Transparent UDP relay listening on 0.0.0.0:8443→[PASS] UDP/QUIC relayed).cargo fmt --check,cargo clippy --workspace --all-targets -D warnings,cargo test --workspace(169) clean on macOS;-D warningsLinux cross-build clean.🤖 Generated with Claude Code