Re: HAProxy proxy protocol support

Paul B. Henson wrote:
> We currently run our openLDAP service on our campus behind an F5 load balancer which preserves the IP address of the connecting client through to the backend
> servers, which we rely on for a small amount of IP address based authorization differentiating between on-campus and off-campus access.
> 
> However, management is strongly pushing us to migrate the service to the Amazon cloud, using Amazon's load balancer. Unfortunately, Amazon's load balancer only
> supports client NAT for directing connections to the back end servers, so they have no idea who the actual client is, it just appears to be the load balancer
> itself.
> 
> Amazon's solution for that is to support HAProxy's proxy protocol in their load balancer:
> 
>     https://www.haproxy.com/blog/haproxy/proxy-protocol/
> 
> Basically, this is an in band signaling mechanism that inserts an additional header in the initial connection data containing the original client IP
> address/source port and destination IP address/source port, allowing the server to utilize that information for the connection rather than the actual details of
> the network connection from the proxy itself.
> 
> This requires support from the application running on the server, as it must remove and process that proxy header from the connection data before moving on with
> whatever data would normally be passed on the connection.
> 
> There are some fair number of services that support this proxy, including of course HAProxy itself, such as the apache web server and the postfix mail server.
> 
> openLDAP does not support the protocol, and I was unable to find any past discussion of it.
> 
> I was wondering if this feature would be something acceptable for inclusion to openLDAP, or if from an architectural perspective it would be considered
> undesirable.
> 
> 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.

> When a connection is accepted on a port marked as requiring the proxy protocol, it would read and process the proxy header to populate the appropriate data
> structures regarding connection, and then move on as it normally would to deal with the connection.
> 
> If this feature is of interest, I will probably spend a little time poking at it and seeing how much trouble it will be to implement.

Doesn't seem too problematic. I would only support the version 2 (binary) header,
seems silly to implement the version 1 support for such an old spec.

-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/