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 <j...@ssi.bg>
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-requ...@linuxvirtualserver.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
