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.
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.
Thanks…
