Re: [PATCH]: Linux Transparent Proxy

On Mon, 2003-03-10 at 16:59, Henrik Nordstrom wrote:
> > 2. You must supply a tcp_outgoing_address in your squid.conf, this is
> > because of some deep magic in the Linux TCP/IP stack. If anyone would
> > like me to explain the reasons more thoroughly just ask.
>
> This is deep magic in the TPROXY extension of the Linux TCP/IP stack I
> suppose?

Well, yeah the TPROXY code is a modular part of netfilter and is simply
implemented as a special-case of NAT. The problem with this approach is
that the TCP/IP stack proper doesn't know about it and for some reason
routing checks carried out in connect() fail unless you bind the socket
to a non-loopback address first (can't remember the exact reason now,
but it seemed non-trivial to fix at the time).

> > 4. I have not tested the autoconf stuff because both my debian and rh8
> > automakes and autoconfs (of varying versions) all failed for one
> > reason or another.
>
> RedHat 8 has the autoconf and automake packages needed in the
> distribution, but you may need to select to install the older versions
> used by Squid-2.5 manually.

Yeah, in the end I managed to just run autoconf and not automake because
the makefiles don't change with this patch :

> > TODO:
> > o Fix server pconns.
> > o Port all changes to cvs HEAD branch.
>
> Required for merging.

Working on it :)

> > o Fix kernel space code so squid doesn't need to run as root.
>
> As a first step CAP_NETADMIN should be used.

Yeah that is what the current check is but as I say this is pretty
useless unless the capability system allows for dropping root privs
while keeping CAP_NET_ADMIN. I'm not too familiar with the capability
syscalls so I'll take a look. Either way CAP_NET_ADMIN is quite a lot of
extra power, would prefer a little finer granularity :)

> > o TPROXY as it is breaks end-to-end requirement of the internet, need
> > to develop a better API for controlling these features from
> > userspace.
>
> TPROXY falls in the same pit of evilness as interception when it comes
> to TCP/IP. Both break the end-to-end criteria of IP networking. Both
> require the network to be properly constructed to deal with the
> breakage, it is only that TPROXY (and other "spoof as client") makes the
> question much more visible.

Yeah, what I think is needed is an API that allows you to retrieve the
original destination address without accepting the connection, then you
can connect out and only accept the client connection if the server
accepts. I don't see how you can get a sane way of doing this based on
the standard sockets API.

Perhaps an noaccept(2) syscall which will do half an accept() - pass the
address info and give you an FD to reference it for future accept()
proper which would complete the handshake. I fear the kernel-side of
that would look horrible....

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D