I thing there is no need to track connction from client to TPROXY server. And what about to move -m socket match and other stuff to the raw conntrack table and then use a -j NOTRACK target to selectively do not conntrack connections from client to tproxy server, while other connections, include from tproxy server to the world , will be still conntracked ? please execuse my wrong english # ------------ Původní zpráva ------------ # Od: KOVACS Krisztian <hidden@sch.bme.hu> # Předmět: Re: [tproxy] tproxy can't work with ip_conntrack # Datum: 22.10.2008 17:30:04 # ---------------------------------------- # 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 # _______________________________________________ # tproxy mailing list # tproxy@lists.balabit.hu # https://lists.balabit.hu/mailman/listinfo/tproxy # # #