On 07/13/2013 12:07 AM, Grzegorz Dwornicki wrote:

Ok thanks for clarification. I thought you might do this in simpler way.



We are doing it in the following way (doesn't matter which load balancer you pick as long as it can preserve the real IP in which ever matter, like in IPVS it's called gateway mode)


the Load Balancer has the Service IP (eq. 192.168.0.1)
  selfIP (192.168.0.2)
  floating (192.168.0.4)
with two nodes configured
    Node1 (eq 192.168.0.5)
    Node2 (eq 192.168.0.6)

most likely on all implementations you'll have the same-subnet restriction to be able to preserve the IP (IPVS can do something like tunnel-mode)

Normally it would work in that way, that you'll need to set the default gateway for both Nodes to the Floating IP (which floats between the LB's in case of failure)
of the LB which then is able to "rewrite" the response and your Nodes will see the real Client IP of the request.

[ client (192.168.1.1) ] -> [ LB (192.168.0.1) ] -> [ Node1 (192.168.0.5) sees 192.168.1.1 ] -> [ LB (rewrites) ]  -> [ client ]

this works fine as long as you have enough network segments and configure them to as minimum possible hosts (net + broadcast + 3 IPs from the LB plus N Nodes)

it's different within the same subnet and in the above example you need to send "everything" which is not in the same subnet (Backup, replication, ...) through the Loadbalancer loosing the Node1/2 outgoing source restriction to possible other services.

We've implemented it using source policy routing, which is more or less the same as above but limits which packets are being sent through the Load balancer to an iptables set of MARK  rules.

So you setup the Node1/2 without changing the default Gateway. You configure iptables to classify (LDAP is quite easy for that) all originated packets from source port 389 to any client except Replication Nodes, to be marked. With source policy routing you define a new routing table for these packets to have the default route set to the Floating IP of the LB.

example: (assume the same IP's as above)

Nodesetup:
$ iptables -t mangle -N LB
$ iptables -t mangle -A  OUTPUT -p tcp --sport 389 -j LB
$ iptables -t mangle -A LB -d 192.168.0.5 -j RETURN  # exclude replication for node2
$ iptables -t mangle -A LB -d 192.168.0.2 -j RETURN  # exclude network IP from LB1
$ iptables -t mangle -A LB -d 192.168.0.3 -j RETURN  # exclude network IP from LB2
$ iptables -t mangle -A LB -j MARK --set-mark 0x1

these rules create a Table (LB) which does nothing for the Replication Node(s) and the Interfaces of the LBs (which in most cases will be used for Health checks)
for anything else it Marks the Packet with 0x1

$ ip route add default via 192.168.0.1 via 192.168.0.4 table  101
$ ip rule add fwmark 0x1 lookup 101 pref 1

those two ip commands create another routing table where packets marked with 0x1 will be sent through the floating IP of the Loadbalancer(192.168.0.4)

this works pretty fine also within the same subnet, only exception if those two nodes need to communicate with the same service name/address (meaning them self authenticating agains LDAP. Then you can only add a "local" dummy IP with the LB Service address so that the packets will stay locally.

regards
mIke



12 lip 2013 23:57, "Justin Kinney" <jakinne+389-users@gmail.com> napisał(a):



On Fri, Jul 12, 2013 at 2:50 PM, Grzegorz Dwornicki <gd1100@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@gmail.com> napisał(a):




On Fri, Jul 12, 2013 at 2:32 PM, Grzegorz Dwornicki <gd1100@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@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 list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users