LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: SNAT Confusion

To: jkrzyszt@xxxxxxxxxxxx
Subject: Re: SNAT Confusion
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: "Rodre Ghorashi-Zadeh" <rodrico7@xxxxxxxxxxx>
Date: Tue, 20 Mar 2007 09:45:08 -0700
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


<Prev in Thread] Current Thread [Next in Thread>