<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/13/2013 12:07 AM, Grzegorz
Dwornicki wrote:<br>
</div>
<blockquote
cite="mid:CAOP-CUf8JGZN8YzD58-QbYxV3fRGDwRZLfmVXotLq2On_0=azQ@mail.gmail.com"
type="cite">
<p dir="ltr">Ok thanks for clarification. I thought you might do
this in simpler way. </p>
</blockquote>
<br>
<br>
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)<br>
<br>
<br>
the Load Balancer has the Service IP (eq. 192.168.0.1)<br>
selfIP (192.168.0.2)<br>
floating (192.168.0.4)<br>
with two nodes configured<br>
Node1 (eq 192.168.0.5)<br>
Node2 (eq 192.168.0.6)<br>
<br>
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)<br>
<br>
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)<br>
of the LB which then is able to "rewrite" the response and your
Nodes will see the real Client IP of the request.<br>
<br>
[ client (192.168.1.1) ] -> [ LB (192.168.0.1) ] -> [ Node1
(192.168.0.5) sees 192.168.1.1 ] -> [ LB (rewrites) ] -> [
client ]<br>
<br>
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)<br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
example: (assume the same IP's as above)<br>
<br>
Nodesetup:<br>
$ iptables -t mangle -N LB<br>
$ iptables -t mangle -A OUTPUT -p tcp --sport 389 -j LB<br>
$ iptables -t mangle -A LB -d 192.168.0.5 -j RETURN # exclude
replication for node2<br>
$ iptables -t mangle -A LB -d 192.168.0.2 -j RETURN # exclude
network IP from LB1<br>
$ iptables -t mangle -A LB -d 192.168.0.3 -j RETURN # exclude
network IP from LB2<br>
$ iptables -t mangle -A LB -j MARK --set-mark 0x1<br>
<br>
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)<br>
for anything else it Marks the Packet with 0x1<br>
<br>
$ ip route add default via 192.168.0.1 via 192.168.0.4 table 101<br>
$ ip rule add fwmark 0x1 lookup 101 pref 1<br>
<br>
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)<br>
<br>
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.<br>
<br>
regards<br>
mIke<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAOP-CUf8JGZN8YzD58-QbYxV3fRGDwRZLfmVXotLq2On_0=azQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">12 lip 2013 23:57, "Justin Kinney" <<a
moz-do-not-send="true"
href="mailto:jakinne%2B389-users@gmail.com">jakinne+389-users@gmail.com</a>>
napisał(a):<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Jul 12, 2013 at 2:50 PM,
Grzegorz Dwornicki <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:gd1100@gmail.com" target="_blank">gd1100@gmail.com</a>></span>
wrote:
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">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? </p>
</blockquote>
<div>
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.<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">12 lip 2013 23:48, "Justin
Kinney" <<a moz-do-not-send="true"
href="mailto:jakinne%2B389-users@gmail.com"
target="_blank">jakinne+389-users@gmail.com</a>>
napisał(a):
<div>
<div><br type="attribution">
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Jul 12,
2013 at 2:32 PM, Grzegorz Dwornicki <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:gd1100@gmail.com"
target="_blank">gd1100@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<p dir="ltr">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 </p>
</blockquote>
<div><br>
</div>
<div>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.<br>
<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div class="gmail_quote">12 lip 2013
23:27, "Rich Megginson" <<a
moz-do-not-send="true"
href="mailto:rmeggins@redhat.com"
target="_blank">rmeggins@redhat.com</a>>
napisał(a):
<div>
<div><br type="attribution">
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF"
text="#000000">
<div>On 07/12/2013 03:25 PM,
Justin Kinney wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Hello,<br>
<br>
</div>
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?<br>
<br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
<br>
</div>
<div>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).<br>
<br>
</div>
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.<br>
</div>
</blockquote>
<br>
I don't know - what are the
TCP/IP/socket API calls that
are required to get this
data?<br>
<br>
<blockquote type="cite">
<div dir="ltr"> <br>
Thanks in advance,<br>
Justin</div>
<br>
<fieldset></fieldset>
<br>
<pre>--
389 users mailing list
<a moz-do-not-send="true" href="mailto:389-users@lists.fedoraproject.org" target="_blank">389-users@lists.fedoraproject.org</a>
<a moz-do-not-send="true" href="https://admin.fedoraproject.org/mailman/listinfo/389-users" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a></pre>
</blockquote>
<br>
</div>
<br>
--<br>
389 users mailing list<br>
<a moz-do-not-send="true"
href="mailto:389-users@lists.fedoraproject.org"
target="_blank">389-users@lists.fedoraproject.org</a><br>
<a moz-do-not-send="true"
href="https://admin.fedoraproject.org/mailman/listinfo/389-users"
target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a><br>
</blockquote>
</div>
</div>
</div>
<br>
--<br>
389 users mailing list<br>
<a moz-do-not-send="true"
href="mailto:389-users@lists.fedoraproject.org"
target="_blank">389-users@lists.fedoraproject.org</a><br>
<a moz-do-not-send="true"
href="https://admin.fedoraproject.org/mailman/listinfo/389-users"
target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
--<br>
389 users mailing list<br>
<a moz-do-not-send="true"
href="mailto:389-users@lists.fedoraproject.org"
target="_blank">389-users@lists.fedoraproject.org</a><br>
<a moz-do-not-send="true"
href="https://admin.fedoraproject.org/mailman/listinfo/389-users"
target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a><br>
</blockquote>
</div>
</div>
</div>
<br>
--<br>
389 users mailing list<br>
<a moz-do-not-send="true"
href="mailto:389-users@lists.fedoraproject.org"
target="_blank">389-users@lists.fedoraproject.org</a><br>
<a moz-do-not-send="true"
href="https://admin.fedoraproject.org/mailman/listinfo/389-users"
target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
--<br>
389 users mailing list<br>
<a moz-do-not-send="true"
href="mailto:389-users@lists.fedoraproject.org">389-users@lists.fedoraproject.org</a><br>
<a moz-do-not-send="true"
href="https://admin.fedoraproject.org/mailman/listinfo/389-users"
target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
389 users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:389-users@lists.fedoraproject.org">389-users@lists.fedoraproject.org</a>
<a class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/mailman/listinfo/389-users">https://admin.fedoraproject.org/mailman/listinfo/389-users</a></pre>
</blockquote>
<br>
</body>
</html>