Re: linux transparent proxy status?

On Fri, Apr 25, 2003 at 05:16:46PM +0100, Gianni Tedesco wrote:

> > - It is possible to automatically determine tcp_outgoing_address by
> > doing an rtnetlink routing table lookup for the target IP address,
> > and then using the 'src' RT attribute from the returned route.
>
> Sounds like a possiblility. You would still need to inform the user that
> they would need an IP on the server facing interface. (I use bridging in
> my setup with nothing but an external facing management IP). You could
> probably just take the IP of the first interface that has one, I think
> the interface doesn't even matter provided it isn't loopback...

Think of a proxy that has a 10.0.0.0/8 interface to a set of
internal servers, and a w.x.y.z/24 interface to the outside world.

Informing the user should be easy: if the route lookup yields no
feasible routes, source-faked connect() will fail, so hand the user
an error page and/or syslog something.

It would reduce the number of Tunables/Settables, which I consider
to be an important thing.

> > - I wrote a patch against the linux kernel in november last year that
> > lets one selectively accept/reject TCP connections. I've put a copy
> > at the following address. The API seems fairly clean. The patch
> > itself needs some bug hunting still, but the basic idea is sound, I
> > think.
> >
> > http://www.math.leidenuniv.nl/~buytenh/marc_boucher_take_2
>
> can you describe briefly how it works from userspace perspective? I
> don't think there is enough context in the patch to make it obvious for
> a kernel llama like me ;)

bind() a listening TCP socket.
setsockopt() TCP_CONFIRM_CONNECT to 1
listen() on it

when connection comes in:
        accept() it. at this point, SYN-ACK is not yet sent.
        if (want to accept this connection) {
                read() or write() from the returned socket. SYN-ACK is sent.
        } else {
                close() before doing anything else. RST is sent.
        }

when TCP_CONFIRM_CONNECT is 0 (default), SYN-ACK is always sent.

in case of accept queue overflow (SYN flood), kernel falls back
to sending syncookies as usual (iff enabled).

unfortunately nobody really picked up the patch.

> > - I would be interested in making it possible for squid to use something
> > like an X-Forwarded-For: header to determine the source IP address to
> > fake for a certain connection. I.e., to preserve a user's source IP
> > address over multiple 'proxy hops' (of course using some kind of ACL
> > mechanism for determining which proxy/proxies to 'trust' this
> > X-Forwarded-For: header from)
>
> hehe, cool idea :)
>
> Sounds like you could have some "interesting" times troubleshooting a
> setup like that but I can see how it would be useful in some scenarios
> :)

:)

My main application would be in a situation where there are two
colocations on either side of the big pond, with Circumstances
preventing hosting part of the application servers on the other
side.

Idea is to put a proxy server on either side, with the server on
one side forwarding requests to the other side, with X-Forwarded-For:
headers, and DNS tricks to make clients end up on the right proxy
server.

In this case, unfortunately the application servers run on Windows,
which sort-of limits my possiblities.

cheers,
Lennert
Received on Fri Apr 25 2003 - 12:34:11 MDT