|
Hello,
I will make some coding and testing this weekend too.
On Fri, 19 Jan 2001, Wensong Zhang wrote:
> > 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;
> }
May be yes. May be we can't avoid the conntrack to be created
from the pre routing but we can try to release the netfilter
connection as soon as possible.
> 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().
Yes, we have two choices:
1. to add code in do_masquerade
2. to add code in the caller, i.e. in fw_in()
May be I prefer the second case.
In either case we will be called twice from FORWARD:
- fw_in (FORWARD:0)
if ipchains.o is inserted
- ip_vs_out (FORWARD:100)
in any case:
1. no ipchains and no iptable_nat/ip_conntrack
2. ipchains only
3. iptable_nat/ip_conntrack
So, may be we can return from fw_in with NF_STOLEN/NF_DROP
after masquerading the LVS related connections. The problem is
how to avoid the second lookup in FORWARD:100 when the connection
lookup fails in FORWARD:0. May be in ip_vs_out we will see that
the connection is created from the netfilter. So, may be we can
call ip_vs_out from many places but may be we will need to mark
the packets as already handled. May be will need some code in
ip_nat_fn for the POST_ROUTING. The PRE_ROUTING comes too in
ip_nat_fn but we can't do anything here. We can't waste CPU for
LVS before LOCAL_IN or FORWARD. So, if the iptable_nat and the
ip_conntrack code is inserted we will have ip_conntrack_in calls
and we have to release this structure as soon as possible if
the iptables rules don't like this packet and leave it to LVS.
The main goals is LVS to work with:
- firewall rules: with ipchains or iptables
- QoS
- masquerading: LVS-only (only for NAT-ed real servers), iptable_nat
rules, ipchains rules
- We must be before any netfilter nat code (mostly in the FORWARD chain).
- The packets after ip_route_output() not to be dropped in the
post_routing from ip_nat_fn
We must make all this working :)
> 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).
I don't like to patch but it looks as the only solution. Let's
make something working and then to optimize it with help from the
netfilter gurus.
> Thanks,
>
> Wensong
Regards
--
Julian Anastasov <ja@xxxxxx>
|
