|
Hello,
On Wed, 17 Jan 2001, Pat O'Rourke wrote:
>
> > There are problems with 2.4 and NAT.
> > Julian has talked about this a bit. You might want to look for his postings
> > on the matter first.
>
> I did, but I somehow got the impression that one could make LVS-NAT work on
> 2.4 using the ipchains compatability module. The changelog also makes several
> references to VS/NAT fixes, so I assumed it would work. Are you saying that
> it does not work? If this is the case, could the README of the ipvs code be
> amended to state that a NAT configure is unsupported for now?
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.
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.
> Thanks for your reply.
>
> Pat
Regards
--
Julian Anastasov <ja@xxxxxx>
|
