|
Hello,
On Thu, 17 Apr 2008, Jason Stubbs wrote:
> On further investigation, the behaviour is the same regardless of whether it
> is a VIP or a real host. When a SYN_SENT state exists traffic doesn't flow.
> However, if there is no state and an ACK (no SYN) packet arrives, an
> ESTABLISHED entry is created such as:
This conntrack does not look good, dst=192.168.1.3 in
original direction is RIP instead of VIP.
Your fw rules are not strict enough, you are using:
iptables -t filter -A FORWARD -d 192.168.0.7 -i eth0 -j ACCEPT
iptables -t filter -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -P FORWARD REJECT
Can you replace first rule to allow traffic to VIP:VPORT
only for NEW. Most users don't allow traffic to any port, they
specify NEW for explicit ports, others are disabled. By this
way we can see if conntrack has valid directions. I suspect
conntracks are not properly confirmed which happens at
POST_ROUTING:NF_IP_PRI_CONNTRACK_CONFIRM. For the original
request we exit with NF_STOLEN and the forwarded request goes
to POST_ROUTING via dst_output call. Somewhere original destination
in conntrack is replaced (or wrongly set).
You can also see the NFCT patch, it plays with conntrack
in the hard way but you can see how IPVS tries to keep conntracks
in good shape.
http://www.ssi.bg/~ja/nfct/
http://www.ssi.bg/~ja/nfct/ipvs-nfct-2.6.24-1.diff
> ipv4 2 tcp 6 431996 ESTABLISHED src=192.168.0.104 dst=192.168.1.3
> sport=20001 dport=80 packets=1 bytes=54 [UNREPLIED] src=192.168.1.3
> dst=192.168.0.104 sport=80 dport=20001 packets=0 bytes=0 mark=0 use=1
>
> After this the connection can complete normally. I wonder if this is not a
> bug
> in conntrack handling? It doesn't seem right to me.
loose flag has different prurpose:
/* If it is set to zero, we disable picking up already established
connections. */
static int nf_ct_tcp_loose __read_mostly = 1;
I hope conntracks are not created per-packet? You have to
check how the conntrack looks in the different cases when playing
with nf_ct_tcp_loose. Addresses before [UNREPLIED] is the original
direction and data for the reply direction is the second part of
addresses. Also, tcp_conntracks[][][] looks valid for SS state
in the original direction, it will not switch to sES for invalid
senders (may be until tcp_loose is set?).
I remember that for NFCT patch tests some packets
were dropped due to TCP SEQ number problems after ip_vs_ftp mangled
the IP addresses in FTP commands. Then I used
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
to solve it because ip_vs_ftp and tcp conntrack do not work
perfectly together.
Regards
--
Julian Anastasov <ja@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
