[tproxy] netcat for tproxy (and additional noob questions)

KOVACS Krisztian hidden at sch.bme.hu
Tue Jul 7 13:22:31 CEST 2009


Hi,

On Sun, Jul 05, 2009 at 03:16:47PM -0400, John Lauro wrote:
> > * create listen socket
> > * setsockopt to make it transparent
> > * bind() to 0.0.0.0, relevant port that you've redirected traffic to
> > * listen() as usual
> > 
> > Then, you accept() as usual, use getsockname() to determine the
> > original destination. Then for the outbound socket:
> 
> Getsockname is returning back the source/client IP & port instead of the
> original destination.  I will need that, but that's only half...  I'm
> possibly just not passing the correct structure(?)  Switching a couple of
> things around, instead it returns back the generic 0.0.0.0 address I bound
> as, which is not any better.  It might not help that I am tested it from a
> slightly modified netcat instead of a more simple test and I am probably
> overlooking something simple.  Perhaps next I'll try a more simple code test
> from scratch instead of patching netcat.

I have a very simplistic patch for netcat here:

http://home.sch.bme.hu/~piglet/netfilter/tproxy/netcat-ip_transparent-support.patch

May or may not work, since it was a long time ago I wrote that.

In theory, getsockname() for the fd returned by accept() should be the
original destination address, while getpeername() should return the
client (source) address.

For UDP, you should be able to get the original destination address via an
ancillary message returned by recvmsg() (You can find the git commit
introducing that feature here:  http://tinyurl.com/n4yjlt)

> > * create socket
> > * setsockopt to make it transparent
> > * bind() to relevant IP (and port, or leave it 0 to let the stack
> > choose a port IIRC)
> Should I be able to reuse the original source port, or will that fail/cause
> problems as it would already be in the connection table (except with
> local/foreign reversed)?

Reusing the original port is usually a bad idea. A notable example of
things breaking is Netfilter connection tracking, which gets confused if
you reuse the exact same endpoints for a different connection.

-- 
KOVACS Krisztian


More information about the tproxy mailing list