What problem are you trying to solve?
When Linkerd proxies an inbound TCP connection to an application running in the same pod, the application sees the Linkerd sidecar as the TCP peer instead of the original client IP address.
For example, when RabbitMQ runs with a Linkerd sidecar, RabbitMQ reports the local Linkerd proxy address for every connection.
This is particularly problematic for non-HTTP protocols such as AMQP, where there is no application-layer header comparable to X-Forwarded-For.
RabbitMQ supports the HAProxy PROXY protocol and can obtain the original source IP from a PROXY protocol v1 or v2 header. However, Linkerd does not currently appear to support sending such a header when forwarding an inbound connection to the workload.
How should the problem be solved?
Linkerd should optionally send a PROXY protocol header when forwarding inbound TCP connections from the inbound proxy to the application.
Ideally, this would:
- Be opt-in, rather than enabled by default
- Be configurable per workload or per inbound port
- Support PROXY protocol v2, and optionally v1
- Include the original client source IP and source port
- Work with opaque TCP protocols
- Be compatible with both meshed and unmeshed clients
- Clearly document that the receiving application must explicitly support and enable PROXY protocol
The exact API is not important, but it should be possible to enable the behavior only for applications and ports that expect a PROXY protocol header.
The feature should also ensure that applications cannot receive forged source addresses from arbitrary clients. The header should be generated by Linkerd itself from the connection metadata known to the proxy, not forwarded from an untrusted inbound PROXY header unless explicitly configured.
Any alternatives you've considered?
Skip the RabbitMQ inbound and outbound ports
Using skip-inbound-ports and skip-outbound-ports preserves the direct TCP connection, but also bypasses Linkerd entirely for that traffic. It additionally requires configuration on both RabbitMQ and every client workload.
How would users interact with this feature?
No response
Would you like to work on this feature?
None
What problem are you trying to solve?
When Linkerd proxies an inbound TCP connection to an application running in the same pod, the application sees the Linkerd sidecar as the TCP peer instead of the original client IP address.
For example, when RabbitMQ runs with a Linkerd sidecar, RabbitMQ reports the local Linkerd proxy address for every connection.
This is particularly problematic for non-HTTP protocols such as AMQP, where there is no application-layer header comparable to X-Forwarded-For.
RabbitMQ supports the HAProxy PROXY protocol and can obtain the original source IP from a PROXY protocol v1 or v2 header. However, Linkerd does not currently appear to support sending such a header when forwarding an inbound connection to the workload.
How should the problem be solved?
Linkerd should optionally send a PROXY protocol header when forwarding inbound TCP connections from the inbound proxy to the application.
Ideally, this would:
The exact API is not important, but it should be possible to enable the behavior only for applications and ports that expect a PROXY protocol header.
The feature should also ensure that applications cannot receive forged source addresses from arbitrary clients. The header should be generated by Linkerd itself from the connection metadata known to the proxy, not forwarded from an untrusted inbound PROXY header unless explicitly configured.
Any alternatives you've considered?
Skip the RabbitMQ inbound and outbound ports
Using skip-inbound-ports and skip-outbound-ports preserves the direct TCP connection, but also bypasses Linkerd entirely for that traffic. It additionally requires configuration on both RabbitMQ and every client workload.
How would users interact with this feature?
No response
Would you like to work on this feature?
None