LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] IPVS with SNAT support on the kernel 2.6.36 + iptables v

To: Ivan Havlicek <ivan@xxxxxxxxxxx>
Subject: Re: [lvs-users] IPVS with SNAT support on the kernel 2.6.36 + iptables v1.4.10
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx, Hannes Eder <heder@xxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Wed, 10 Nov 2010 01:10:53 +0200 (EET)
        Hello,

        CC-ing the author: Hannes Eder

On Tue, 9 Nov 2010, Ivan Havlicek wrote:

> Hi,
>
> I try to use IPVS with SNAT support on the kernel 2.6.36 + iptables
> v1.4.10 without success :
>
> So, Adding the SNAT :
> iptables -t nat -I POSTROUTING -m ipvs --vaddr 88.190.12.128 --vport
> 80 -j SNAT --to-source 10.1.3.254

        I have a doubt, conn_out_get is used with inverse
flag. In this way it can match only requests from client
to real server with LVS-NAT method. It is not universal match
but may be the idea is to work at least for POST_ROUTING SNAT
after LVS-NAT.

        What lookup to use depends on what we need to match,
here is actual information what can be matched depending on
the hook:

                request                         reply
-----------------------------------------------------------------------
PRE_ROUTING     conn_in_get, inverse=0          conn_out_get, inverse=0
LOCAL_IN        conn_in_get, inverse=0          conn_out_get, inverse=0
FORWARD         can not match                   conn_out_get, inverse=0

Special cases:

POST_ROUTING for LVS-NAT:
POST_ROUTING    conn_out_get, inverse=1         conn_in_get, inverse=1
POST_ROUTING for LVS-DR:
POST_ROUTING    conn_in_get, inverse=0          conn_in_get, inverse=1
                                                for forward_shared=1

LOCAL_OUT before 2.6.37-rc1 for LVS-NAT:
LOCAL_OUT       conn_out_get, inverse=1         conn_out_get, inverse=0

LOCAL_OUT before 2.6.37-rc1 for LVS-DR:
LOCAL_OUT       conn_in_get, inverse=0          conn_in_get, inverse=1

LOCAL_OUT after 2.6.37-rc1 for LVS-NAT, scheduling in LOCAL_IN:
LOCAL_OUT       conn_out_get, inverse=1         conn_out_get, inverse=0

LOCAL_OUT after 2.6.37-rc1 for LVS-NAT, scheduling in LOCAL_OUT:
LOCAL_OUT       conn_in_get, inverse=0          conn_out_get, inverse=0

LOCAL_OUT after 2.6.37-rc1 for LVS-DR:
LOCAL_OUT       conn_in_get, inverse=0          conn_in_get, inverse=1

LVS-TUN can not be matched after forwarding because the
packet is already IPIP.

        If the match is used for table nat then may be
only the request can be matched.

> But the iptables rule doesn't work :
> # iptables -vn -t nat -L POSTROUTING
> pkts bytes target     prot opt in     out     source
> destination
>    0     0 SNAT       all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           vaddr 88.190.12.128 vport 80 to:10.1.3.254
> (tcpdump show any snat translation too)

        Strange, for LVS-NAT conn_out_get, inverse=1 is
correctly used because the request packet is already
DNAT-ed by IPVS. May be something else fails.

> And when I try to have all ipvs traffic log :
> iptables -t nat -I POSTROUTING -m ipvs --vaddr 88.190.12.128 -j LOG
> --log-prefix "ipvs/POSTROUTING : "
> # iptables -vn -t nat -L POSTROUTING
> pkts bytes target     prot opt in     out     source
> destination
>    0     0 LOG        all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           vaddr 88.190.12.128 LOG flags 0 level 4 prefix
> `ipvs/POSTROUTING : '
> I've no output...
>
> Did I miss something ?
> Any help welcome.

Regards

--
Julian Anastasov <ja@xxxxxx>

_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

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