|
Hi Janusz,
Thanks for your response, I think I am getting closer.
In theory, yes, but I can not see any way to do it on LVS director, neither
with Julian's conntrack patch (POSTROUTING nat not traversed, so netfilter
SNAT not working), nor my patch (works only for LVS-DR method).
I am using LVS-DR and not LVS-NAT. I tried this with your SNAT patch in
place but it wasn't working, even though I could see the packets being
SNAT-ed to the "token" ip address, both in the iptables counters and with
tcpdump.
Also, I tried SNAT-ing the initial request from the realserver to a "token"
ip address and used routing on the director in LVS-DR mode to send the
replies back to the client/realserver (your recommendation #3) but this
didn't work for me either. Could you explain this setup a little better?
Thanks.
~Rodre
From: Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx>
To: Rodre Ghorashi-Zadeh <rodrico7@xxxxxxxxxxx>
CC: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: SNAT Confusion
Date: Tue, 20 Mar 2007 12:49:51 +0100
Rodre Ghorashi-Zadeh napisa³(a):
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:
Yes, it sounds reasonable, but still does not solve the problem of director
dropping packets with source address matching one of its own addresses.
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)
To avoid confusion, I would describe this as below, using your "token" term
for realserver1 SNATed IP, DMAC and RMAC1 meaning director and realserver1
MAC addresses:
1. realserver1 client: connect from RIP1:* to DMAC:VIP:389
2. director: LVS-NAT VIP:389 to RIP1:389 and netfilter SNAT RIP1:* to
token:*, send to RMAC1:RIP1:389
3. relaserver1 service: answer from RIP1:389 to DMAC:token:* (DMAC resolved
as MAC address of default gateway IP in your setup)
4. director: LVS-de-NAT RIP1:389 to VIP:389 and netfilter de-SNAT token:*
to RIP1:8, send to RMAC1:RIP1:*
In theory this should work, no?
In theory, yes, but I can not see any way to do it on LVS director, neither
with Julian's conntrack patch (POSTROUTING nat not traversed, so netfilter
SNAT not working), nor my patch (works only for LVS-DR method).
Assuming you keep using LVS-NAT method, you could try to set up netfilter
SNAT of RIP1:*->VIP:389 to token:*->VIP:389 on the realserver itself and
teach the director where to find "token" (solution 3 from my prevoius
message). It sholud work without any IPVS patches.
Janusz
_________________________________________________________________
Don?t waste time standing in line?try shopping online. Visit Sympatico / MSN
Shopping today! http://shopping.sympatico.msn.ca
|
