Hello,
You are right, the problem is probably related to source address matching
VIP configured on the director.
This is what I initially thought so what I did was SNAT the source address
(on the director) to be what I will refer to as a "token" IP address, in
this case 101.101.101.101, and set the default gateway on the realserver to
be the director, thinking that when the the realserver replies it would not
now how to route to 101.101.101.101 and send it back to the director, which
would have an entry in it's conntrack, and SNAT it back to the original
address, which is the realserver:
realserver1 client (10.0.0.1:2777) -> director VIP (10.0.0.200:389) -> DNAT
10.0.0.200:389 to 10.0.0.1:389 and SNAT 10.0.0.1:2777 to
101.101.101.101:2777 -> send packet to realserver1 service (10.0.0.1:389) ->
director gateway IP 10.0.0.254 -> SNAT 10.0.0.1:389 to 10.0.0.200:389 and
DNAT 101.101.101.101:2777 to 10.0.0.1:2777 -> realserver1 client
(10.0.0.1:2777)
In theory this should work, no?
~Rod
From: Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx>
To: Rodre Ghorashi-Zadeh <rodrico7@xxxxxxxxxxx>
CC: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: SNAT Confusion
Date: Mon, 19 Mar 2007 14:06:33 +0100
Rodre Ghorashi-Zadeh napisa³(a):
I can see the traffic being SNAT-ed and hitting the realserver and being
sent back but then packet trail just seemed to drop off. I figure it is
because the kernel on the director is probably looking at the source
address of the reply packet, which matches the VIP ip that is on the
director, and is saying "hey, I didn't send this!" and is dropping the
packet. What am I not seeing here? What am I missing? What I guess I need
here is the so called f5 style SNAT? How can I achieve what I need to do?
Rod,
Sorry, I have read the thread in reverse direction and have missed this
important point while sending my previous reply. You are right, the problem
is probably related to source address matching VIP configured on the
director. I can think of three possible solutions:
1. Try to find and apply an IPVS-related patch that allows a director to
accept packets with source address matching one of its own addresses (I
have no experience with this patch).
2. Remove VIP from your director and use static routing / proxy arp and
netfilter marking instead (this is my way of doing things). If you do need
VIP on your director for other clients to work, use an additional VIP
configured this way for accessing your realservers just from themselves via
LVS.
3. Do SNAT on your realservers when acting as LVS clients, not on the
director (I had this working some time ago, but removed this config as I do
not need it anymore).
Cheers,
Janusz
_________________________________________________________________
Have Some Fun Out Of The Sun This March Break
http://local.live.com/?mkt=en-ca/?v=2&cid=A6D6BDB4586E357F!142
|