Hi, On sze, okt 22, 2008 at 04:11:09 +0800, Dong Wei wrote:
I think that we can add some new fields to identify the two HTTP connections in ip_conntrack structure(one is Client->TPROXY Server, and the other is TPROXY Server->HTTP Server). I hope we can get the right conntrack when we just know the tuple containing src_ip,src_port,dst_ip,dst_port. Because there is lots of kernel code like this:
1. get the tuple 4 fields(src_ip,src_port,dst_ip,dst_port) from skb 2. call: nf_conntrack_find_get(tuple) to find the corresponding ip_conntrack. So in this case we can only know the 4 fields, we can't get any more message from skb.
Assuming there are 2 ip_conntrack: [1]: 192.168.2.2:12345->192.168.1.2:80(client->TPROXY Server) [2]: 192.168.2.2:12345->192.168.1.2:80(TPROXY Server->HTTP Server) When we process TCP packets between client and TPROXY Server, we find the conntrack for 192.168.2.2:123456->192.168.1.2:80, the result should be [1], and if the TCP packets belong to TPROXY Server and HTTP Server connection, the result should be [2]
Does anyone have good idea about the requirement mentioned above?
I think most users work around the problem: you usually don't really need the source port to be preserved exactly and by choosing a different source port the problem goes away.
(If you don't care about the source port then bind the socket to port 0 and the kernel will choose an unused port.)
Thanks for your reply. But, I think maybe this solution still have problems.
Here is a sample: Client -> TPROXY Server (192.168.2.2:12345 ->192.168.1.2:80) TPROXY Server -> HTTP Server(192.168.2.2:54321->192.168.1.2:80) Now the two connections have different ip_conntrack. TPROXY Server use port 54321 instead of 12345 as src port
Next time, the client connect to the HTTP Server Client -> HTTP Server(192.168.2.2:54321 -> 192.168.1.2:80). Now Client use the port 54321 connecting to 192.168.1.2:80(This is common for a NAT server connecting to the same HTTP Server using different src port) When TPROXY receive this packet, and find ip_conntrack. It will match the old one - TPROXY Server -> HTTP Server.
This still exist the ip_conntrack conflict.
Yes, and unfortunately you can't do much about that if you're using connection tracking. (Except for implementing some method of differentiating between the two conntracks in ip_conntrack/nf_conntrack, of course.) -- KOVACS Krisztian