On Thu, Mar 28, 2002 at 05:55:25PM +0100, Henrik Nordstrom wrote: > > an entry is removed from this table when > > > > 1) the socket associated with the entry is destroyed (iff a socket is > > associated with an entry) > > Ok. So there is integration between the tproxy table and the host IP stack > somehow, to keep the TPROXY table in sync with the host IP stack. Nice. Kind > of missing in conntrack..
Until now the only binding between the socket and the entry was the address of the local socket. This might have to be changed due to the problem you described below. > > 2) when a TCP rst is returned by the stack (happens only when a socket is > > not yet associated) > > Why this? And doesn't it allow for an easy DOS on TPROXY sessions? > > You should not be processing RST unless you are also processing TCP widows. > Not all RST packets resets "the" session. > > Ah, I think I understand now. You only do this when there isn't yet a socket > in the host IP stack. In such case it is needed. yes, an alternative would be a hook in the kernel which is called when a socket was not found to an incoming SYN. this is an ugly hack though. > Sounds like it could be made to work for TCP. > > UDP is a bit different thou.. but there isn't that big need of a any > connection table there, except for ICMP processing. For UDP I only want to do half-NAT, which means that it would be possible to send a UDP frame with a custom IP address, and receive one destined to somebody else. ICMP processing is needed when we send an UDP frame (with foreign source address), and the destination host returns an ICMP error to the sender. In Linux 2.2 we do the following as a transparent proxy with UDP traffic: * we have a sender socket, which we use to send packets with specified source AND destination address * prior to sending a packet we create, bind and connect a socket to a destination we are sending packets to (this socket receives ICMP errors) A similar approach is doable: * the source address is specified in a control message of sendmsg() * this doesn't create a translation entry in TPROXY * a separate socket is created, and a setsockopt is issued, which places socket related information into the translation table * when an ICMP error is received, the second socket is found, and ICMP error is rewritten accordingly * if no specific socket is found, it is forwarded (and dropped on the forward chain) > > Hmm.. regarding ICMP. How do you plan on handle ICMP from the host stack > without TCP window tracking? > > Problem: There may be multiple sessions from the same client IP,PORT to the > same PORT on multiple servers, and after NAT there isn't sufficient > information to distinguish these by the addressing alone. > > 10.0.1.4:52346 -> 192.168.96.32:80 > 10.0.1.4:52346 -> 192.168.84.253:80 > 10.0.1.4:52346 -> 176.16.48.52:80 > > The problem is much more evident if you look at UDP traffic, but exists for > TCP as well. For TCP you can easily see this if there is multiple clients > behind a NAT gateway (for example netfilter SNAT). > > Hmm.. this problem probably also applies to the de-NAT:ing of traffic, but > there you can probably get by by querying the socket for the real source > address (original destination address). Hmm... this is a real problem, but I only see this occuring in our case when we redirect a session, and responses must be de-NATed. In this case however skb->sk is unique (except for maybe SYN-ACK, because socket is not created until the three-way handshake is fully completed) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
