Michael Ströder wrote:
On 11/19/20 5:04 PM, Howard Chu wrote:
Paul B. Henson wrote:
In general, I believe applications listening on a specific port are either expecting the proxy protocol header, or not, I do not think it is dynamically determined. As such, from an implementation perspective, my initial thought is that it would be implemented in terms of configuration as an additional URL specified via the -h option, something like "ldapp://" or "ldap_p://", "ldapsp://" or "ldaps_p://" or whatever seems most desirable. A server might listen on the standard ports accepting only proxied connections, or it might listen for normal connections on the standard ports and for proxy connections on alternative ports.
Yeah, that agrees with my read of the document. I think "ldapp://" and "ldapsp://" would be usable.
My suggestions:
- Config directives for specifying IP address(es) and network(s)
expected and trusted to send proxy protocol header.
Sounds like unnecessary work. Just use an ACL.
- Separate who peernamestyle for explicitly using the proxied IP
addresses in ACLs. This would allow to specify ACLs with client-proxy relationship.
Yeah, maybe. Although I see this adding extra burden: if you have an existing deployment with peer-based ACLs, you will have to rewrite all of them after the proxy server is in place. I thought the entire point of adopting HAproxy protocol was so that you could continue operating with the client's addresses *transparently*. If you have to rewrite all of the rules regardless, I don't see any reason to bother with HAproxy.
- Log the proxied peername separately, similar how session tracking
control is logged.
Again, kind of defeats the purpose of transparently relaying the client's address.