[tproxy] udp + tproxy

[Balazs Scheidler]

On Wed, 2008-11-12 at 19:59 +0100, KOVACS Krisztian wrote:
> Hi,
> 
> On sze, nov 12, 2008 at 11:40:30 +0000, Andrey Luzgin wrote:
> > Hello,
> > 
> > While I can see example of using udp on tproxy2 onto the
> > redirect-udp-recv.c
> > file, I can't find equivalent on tproxy4.
> > 
> > For getting the original destination IP, I just use setsockopt
> > IP_PKTINFO:
> > setsockopt(sd, SOL_IP, IP_PKTINFO , &flags, sizeof(flags));
> > 
> > But I don't know how to get the original destination port:
> > 
> > a) I manually defined IP_RECVORIGADDRS  to be 11273 as I find on
> > tproxy2:
> > setsockopt(sd, SOL_IP, IP_RECVORIGADDRS , &flags, sizeof(flags));
> > but the setsockopt failed.
> > 
> > b) the getsockname give me the server listening port.
> 
> 
> Since tproxy 4 (unlike tproxy 2) doesn't modify the incoming packets in
> any way you should be able to get the correct destination address by
> simply calling recvfrom() and using the source address returned by the
> kernel.
> 

This is not true, recvfrom() returns the client address and does not
return the original destination. There was a hack in 2.2 kernels, that
it could return the targeted address in the 2nd half of the "struct
sockaddr_in" structure.

But that hack was crude. 

I can only see two options to proceed with full udp proxying: accept()
support for UDP, or a recvmsg() ancillary data (IP_RECVORIGADDRS) as
above.

I'll see whether I can come up with a patch for the latter.

In Zorp we're using accept() for UDP sockets, but I doubt it could be
integrated to mainline, the other option is doable, although potentially
racy.

-- 
Bazsi