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/
