Re: HAProxy proxy protocol support

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/