On Fri, Jul 12, 2013 at 2:28 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
On 07/12/2013 03:25 PM, Justin Kinney wrote:
Hello,
I'm investigating the possibility of logging client IP address where
389ds is deployed behind a load balancer. Today, we lose the true client IP
address as the source IP is replaced with the load balancer's before the
packet hits the 389 host. Has anybody solved this issue before?
For HTTP based services, this problem is trivial to overcome by grokking
the X-Forwarded-For header from the request, but obviously this doesn't
work with a service like LDAP deployed behind a TCP based load balancing
instance.
One option is to use a direct server return (DSR) configuration with our
load balancer and host, but that adds a lot of overhead to our environment
in terms of configuration complexity, so I'd like to avoid that.
Another option is using an interesting capability of our load balancer
(and I'm not sure how unique this feature is - I'd be interested in hearing
if anyone else has run across it). It can insert the client IP address into
the TCP stream, as arbitrary data in the options field of the TCP header.
Existence of an address is also indicated by a magic number (which can
uniquely identify the VIP on the load balancer).
What would it take to modify 389 to access the raw TCP header, parse the
options field to get the true client IP, and then associate it with the
request? Ideally, the client IP would be accessible in the access log.
I don't know - what are the TCP/IP/socket API calls that are required to
get this data?
To be honest, I'm not sure. The data I need may be available by using
getsockopt() at the TCP level or PR_GetSocketOption(). Or possibly by
accessing the PRSocketOptionData associated with the connection. I still
need to do some digging in that regard.
Thanks in advance,
Justin
--
389 users mailing
list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users