Re: TRANSPARENT PROXY and Squid

Hi Jonathan

> [snip]
> >I have done some tests about Transparent proxying :
> [snip]
>
> Of course this won't work for ftp or gopher. Certainly ftp is still used a
> lot these days.
There is already stuff to do this in Linux, as far as I know...

> Also pressing Shift-Reload in a browser may not work as expected because the
> browser potentially doesn't include a Pragma: no-cache (or equivalent)
> without a proxy.
Netscape does, even if the proxy is not turned on. I can't vouch for
MSIE though... It doesn't seem to handle proxies well at all.
(And I run an all-Linux system)

> It seems reasonable. Although I don't see why you should change squid. Why
> not have a little helper app which makes the request to localhost:3128 in
> the correct format. It then returns the data back. Basically a squid proxy
> proxy :-). Obviously use a daemon based on select() rather than something
> from inetd.
I must admit, this is a good idea! You could implement security at this
level too, if you want certain people not to be able to connect, or
stop connections to specific sites etc. It could save the whole mess
about "how do I stop people connecting to www.playboy.com"...
You could base the whole thing on password authentication too.

Basically it functions as does the current linux code, which kind of says:
if it is to port 80, send it to port 3128, but in this case you say,
if it is to port 80, send it to port 80, where it is re-directed by a
program to port 3128.

Logging would have to be done at this level, and you would have to say
something like "acl deny !localhost", and then connect to the
original squid via 127.0.0.1 (Or otherwise someone could just point their
cache at the correct "higher" port number...)

It should also do logging in the standard logging formats (note plural <grin>)
so it can work with the standard log analysis scripts.

It would also have to understand the squid acl's (they seem the best way
of limiting access etc)

It would be optimal to develop both at once (otherwise people will end up
chasing each other to stay up with acl developments, etc), but it is
a quite specialised use...

> This could be distributed with squid, but doesn't have to be part of it, not
> least because its only relevant for the Linux implementation.
Well - I know that the Linux firewall code is based on a FreeBSD port.
It may be relevant under the gauntlet firewall too... Don't think firewall
one would handle it, since it is predominantly (read all) packet filter
based...

Anyone want to move this topic off this list? (I know we linux junkies are
incredibly talkative ;)

Oskar
Received on Thu Sep 12 1996 - 18:04:35 MDT