LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: 2.4 LVS-NAT config question

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: 2.4 LVS-NAT config question
Cc: "Pat O'Rourke" <orourke@xxxxxxxxxxx>
From: Wensong Zhang <wensong@xxxxxxxxxxxx>
Date: Fri, 19 Jan 2001 02:12:51 +0800 (CST)
On Wed, 17 Jan 2001, Julian Anastasov wrote:

> 
>       Yes, it is really unsupported. The tests with ipchains.o were
> long time ago. It seems LVS can work with ipchains.o only for firewalling.
> LVS hooks in FORWARD after the FILTER but it seems ipchains.o makes
> firewalling and masquerading in one hook. So, the priorities don't play
> here. Patching is required to place LVS between the FORWARD firewall and
> the outgoing masquerade. But this is my first impression from the code in
> ip_fw_compat_masq.c:do_masquerade() and ip_fw_compat.c:fw_in().
> 
>       If you don't create any other outgoing masquerading connections
> from the internal servers you can just delete the ipchains rule. The LVS
> will maintain its connections without the help from ipchains. Even for
> the related ICMP messages. Use ipchains rules only for filtering in this
> case.
> 

Hi Pat,

Julian is right. The VS/NAT in 2.4 should work when there is no
masquerading rule specified. If your real servers don't need to access
the outside through the director (issue new connections), you can remove
the ip_conntrack module for performance.
 
>       In your tests the SYN+ACK replies hit the ipchains masquerading
> and the packet don't reach the LVS ip_vs_out() function. The netfilter
> treats this as a new connection and masquerades the packets before
> reaching LVS in the same chain.
> 
>       The other problem in ip_fw_compat_masq.c is that inet_select_addr
> is still involved in the routing decisions. This is wrong. The result
> is that always the primary address from the outgoing device is selected
> as masquerading address instead of using rt->rt_src as maddr.
> 
>       Wensong! IMO, we should make some fixes to support the ipchains
> compatibility mode.
> 

Yeah, we should do it long time ago. But it is not easy to do a good fix
on this, because conntrack tracks every incoming packet. :)

Just thought a dirty fix to support this kind of compatibility. We can
add several lines of checking code in the tcp_packet() of the
ip_conntrack_proto_tcp.c as follows:
        if (oldtcpstate == TCP_CONNTRACK_NONE
            && tcph->syn && tcph->ack) {
                /* release conntrack entry immediately*/
                ...

                return -1;
        }

Add some code in the do_masquerade() as follows:
        if (!ct && iph->protocol == IPPROTO_ICMP) {
                struct tcphdr *tcph = (struct tcphdr *)((u_int32_t 
*)iph+iph->ihl);
                if (tcph->syn && tcph->ack) {
                        /* let it continue traversal */
                        return NF_ACCEPT;
                }
        }

The first change lets tcp_packet delete the conntrack entry when the syn
and ack flag of the packet are set up and it is in NONE state. The
second change lets this kind of packet continue traversal, so that it
can be caught by the ip_vs_out().

I haven't tested it, and don't know if it really works. I just came back
to my parent's home for the Spring Festival (Chinese lunar new year),
don't have hardware to test it now. Anyway, I will try to borrow some
machines to build a development environment at home (because I will stay
here for two weeks).

Thanks,

Wensong

> > Thanks for your reply.
> >
> > Pat
> 
> 
> Regards
> 
> --
> Julian Anastasov <ja@xxxxxx>
> 
> 
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
> 




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