I believe I'm not the first one who tries to solve the PROXY PROTOCOL vs no PROXY PROTOCOL traffic problem for a single listener. This is a very common behavior for k8s clusters that use PROXY_PROTOCOL based loadbalancers.
In short, the k8s pods clients local traffic doesn't use PROXY PROTOCOL, therefore accessing the service locally that expects PROXY PROTOCOL fails. There are two dirty solutions for this: route local traffic to the external loadbalancer IP (to add the required header), or fallback due to timeout.
Both options above have flaws: LB adds latency and load, timeout adds latency and acts unpredictably on heavy load.
I know that it's possible to create an extra wrapper around the original Conn, but this would look dirty. I propose to add a new SKIP policy, which will treat a connection as a regular one and it won't trigger proxyproto handlers. The SKIP policy can be defined in a PolicyFunc callback.
pires
commented
1 year ago
I believe I'm not the first one who tries to solve the PROXY PROTOCOL vs no PROXY PROTOCOL traffic problem for a single listener. This is a very common behavior for k8s clusters that use PROXY_PROTOCOL based loadbalancers.
In short, the k8s pods clients local traffic doesn't use PROXY PROTOCOL, therefore accessing the service locally that expects PROXY PROTOCOL fails. There are two dirty solutions for this: route local traffic to the external loadbalancer IP (to add the required header), or fallback due to timeout.
Both options above have flaws: LB adds latency and load, timeout adds latency and acts unpredictably on heavy load.
I know that it's possible to create an extra wrapper around the original Conn, but this would look dirty. I propose to add a new SKIP policy, which will treat a connection as a regular one and it won't trigger proxyproto handlers. The SKIP policy can be defined in a
PolicyFunccallback.Objections?