Description
Currently, deploying pqc-proxy in legacy environments requires manually modifying client application configurations or environment variables to point to the local listener (e.g., localhost:3000). In complex enterprise infrastructures, some legacy applications use hardcoded destination IPs or dynamically allocated ports, making manual reconfiguration impossible.
To make pqc-proxy a truly seamless sidecar/ambassador solution, we need to support transparent proxying.
Proposed Solution
- Add a new configuration mode or flag (e.g.,
-transparent).
- Utilize Linux
iptables / nftables rules to intercept and redirect outbound TCP traffic to pqc-proxy automatically.
- Use
SO_ORIGINAL_DST via golang.org/x/sys/unix to retrieve the original destination IP and port from the intercepted connection, allowing the proxy to establish the PQC tunnel transparently.
Benefits
- Allows dropping
pqc-proxy into existing infrastructures without altering a single line of code or configuration in legacy apps.
- Simplifies multi-service container mesh deployments (e.g., Docker/Kubernetes sidecars).
Description
Currently, deploying
pqc-proxyin legacy environments requires manually modifying client application configurations or environment variables to point to the local listener (e.g.,localhost:3000). In complex enterprise infrastructures, some legacy applications use hardcoded destination IPs or dynamically allocated ports, making manual reconfiguration impossible.To make
pqc-proxya truly seamless sidecar/ambassador solution, we need to support transparent proxying.Proposed Solution
-transparent).iptables/nftablesrules to intercept and redirect outbound TCP traffic topqc-proxyautomatically.SO_ORIGINAL_DSTviagolang.org/x/sys/unixto retrieve the original destination IP and port from the intercepted connection, allowing the proxy to establish the PQC tunnel transparently.Benefits
pqc-proxyinto existing infrastructures without altering a single line of code or configuration in legacy apps.