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: > > 1. 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. > 2. 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. > 3. 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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
