[389-users] Accessing TCP options data in 389ds Hello,

[Justin Kinney]

On Fri, Jul 12, 2013 at 2:28 PM, Rich Megginson <rmeggins at 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 at lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20130712/0ebf86ac/attachment.html>