RE: lvs-nat & SNAT

To: Rodger Erickson <rerickson@xxxxxxxxxxxx>
Subject: RE: lvs-nat & SNAT
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Tue, 29 Jan 2002 23:47:56 +0000 (GMT)

On Tue, 29 Jan 2002, Rodger Erickson wrote:

>       Julian,
>       If you need for the response from a real server to go through a
> specific director (as seems to be the case in the original diagram provided
> on this question) then you need to SNAT all packets from the director to the
> real server (and unSNAT them when they flow in the other direction).  This

        With one IP for SNAT may be this setup is limited to
65K connections. I'm not sure the NAT is the recommended method.

> is also needed in the scenario where LVS is providing high availability
> within a cluster (i.e. the "clients" are in the same subnet as the real
> servers).  If these LVS packets aren't SNAT'd then the real server will send
> the responses directly to the clients and TCP will break).

        Each problem has its solution. Any NAT setup can be
replaced with DR. Also, both LBs can DNAT to different real
server IPs or ports. Then the routing is clear.

>       Given the current implementation, it is impossible to SNAT a packet
> that LVS has modified.  The ip_vs_post_routing() hook steals all LVS-handled
> packets.  Thus SNAT and conntrack never get to see these packets.

        True, the xmitters do it in the out->in direction.

>       It's pretty clear in the code.  I've also verified this empirically
> by creating my own NF_IP_POST_ROUTING hook at the "location" where SNAT
> would have been (NF_IP_PRI_NAT_SRC).  In these cases, my hook never sees
> anything that LVS has modified (but it sees everything else).  If I remove
> the LVS NF_IP_POST_ROUTING hook then my hook sees the packets and the
> SNATing can occur.

        You better to remove the flag from the xmitters. The
post_routing function is needed for the in->out LVS direction.

> >     They are already SNAT-ed from LVS.
> LVS only changes the source address for packets it forwards back to the
> client -- it doesn't SNAT in the director-to-real_server direction -- which
> is what is needed here.

        I now see what you mean.

> >     LVS does not touch the netfilter's conntrack packets,
> > they reach unchanged post_routing where they can be SNAT-ed
> > if such manipulation is scheduled from netfilter.
> I don't think this is true.  All NF_IP_INPUT packets that LVS modifies are
> stolen by the ip_vs_post_routing before SNAT and conntrack get to see them.

        I have never thought someone will use it in this way.

>       Rodger Erickson


Julian Anastasov <ja@xxxxxx>

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