[tproxy] tproxy can't work with ip_conntrack

[Dong Wei]

Hi,all

When I use a transparent proxy application using tproxy, I find there
is something wrong when I load ip_conntrack module
Here is a sample:
network topology(router mode):
Client[192.168.2.2]--------[192.168.2.1]TPROXY
Server[192.168.1.1]--------[192.168.1.2]HTTP Server

1. Client try to connect to HTTP Server, and TPROXY Server redirect
the traffic to itself. Now the conntrack is:
ORIG: 192.168.2.2:12345->192.168.1.2:80 REPLY:192.168.1.2:80->192.168.2.2
After 3 way handshake the connection between Client and TPROXY server
should be in ESTABLISHED state

2. TPROXY Server connect to HTTP Server using fake src ip and src
port. Now the SYN packet should be
192.168.2.2:12345->192.168.1.2:80. But kernel find there is an old
ip_conntrack entry for this SYN packet whose state is ESTABLISHED
So, kernel will drop the SYN packet, and delete the old entry

3. SYN packet will be retransmitted after 1 sec on TPROXY Server. And
then kernel will allocate an new entry for this SYN packet.

4. After 3 way handshake between TPROXY Server and HTTP Server, this
ip_conntrack entry should be in ESTABLISHED state


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?



-- 
Thanks
BR. Wei Dong