Re: TPROXY support in Squid 3

On Tue, Apr 08, 2008, Henrik Nordstrom wrote:
>
> tis 2008-04-08 klockan 14:28 +0800 skrev Adrian Chadd:
> > Take 2: includes initial modularisation (untested; I'll test it at home
> > this weekend when I get my tproxy box back online) and configure magic
> > (with placeholders for tproxy4/freebsd.)
> >
> > http://www.creative.net.au/diffs/20080408-tproxy-fix-2.diff
>
> Comments:
>
> commTransparentRemote needs to move into comm_openex. You can't fit
> tproxy4/freebsd in a reasnoable manner otherwise.

Yup, that'd be part of the follow up work. This first cut is to break out what
is there; the next commit would be further API tidyups to support TPROXY4
and FreeBSD.

> By removing the need_linux_tproxy you just killed the capability to fall
> back no non-tproxy connections if we failed to gain the capabilities
> needed.. cache.log will now get filled with tons of errors in such
> setups., where you earlier only got a single warning about continuing
> without tproxy support..

Yes, I have to give that a little more thought. I may keep the global but
not call it "linux_tproxy"..

> > * pull out the capabilities stuff, removing the last #ifdef LINUX_TPROXY
> > from the source
>
> TPROXY both versions need the special capabilities, and we do not want
> to keep these capabilities if TPROXY is not used..

Ok.

> > * make sure upstream/peer-forwarded requests aren't thrown to the tproxy
> > code.
>
> Consider a local proxy connecting to a remote proxy. You may want to
> still show the actual client IPs to the remote proxy just as you do to
> websites..
>
> A cache_peer flag controlling this would make sense, probably defaulting
> to not spoof the client ip on requests sent to peers..

I read the current code as "don't do that"; its the behaviour I'd like to
maintain. We can always add the functionality later.

Adrian

-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -