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

[Justin Kinney]

On Fri, Jul 12, 2013 at 2:50 PM, Grzegorz Dwornicki <gd1100 at gmail.com>wrote:
>
> That is true but load balancer iptables see incoming requests as they are.
> I'm not sure that this is what you need. What information you wish to
> receive? Besides the real client IP?
>
At the moment, the search node behind the load balancer sees the source of
all requests as the egress interface of the load balancer. Access to the
load balancer is not possible, but it can insert the data as described into
the options field of the TCP header, and so it may be possible to do
something with iptables on the search node. The goal here (if possible) is
simply to log the true client IP address in the access log of the search
node.

12 lip 2013 23:48, "Justin Kinney" <jakinne+389-users at gmail.com> napisał(a):
>
>
>>
>>
>> On Fri, Jul 12, 2013 at 2:32 PM, Grzegorz Dwornicki <gd1100 at gmail.com>wrote:
>>
>>> Are you doing this on loadbalancer? You can use iptables with log target
>>> but if this is not sufficient, then some kind of sniffer like tcpdump might
>>> be helpful
>>>
>>
>> The loadbalancer will add the client ip address to the TCP options field
>> of the client request prior to passing to the servicing node behind the LB.
>>
>>
>>> 12 lip 2013 23:27, "Rich Megginson" <rmeggins at redhat.com> napisał(a):
>>>
>>>  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?
>>>>
>>>>
>>>> Thanks in advance,
>>>> Justin
>>>>
>>>>
>>>> --
>>>> 389 users mailing list389-users at lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>>
>>>>
>>>> --
>>>> 389 users mailing list
>>>> 389-users at lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>
>>> --
>>> 389 users mailing list
>>> 389-users at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>
>>
>> --
>> 389 users mailing list
>> 389-users at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20130712/a3d77cd4/attachment.html>