On 29.09.16 16:39, Henry Paulissen wrote:
In the company I work for we are currently using squid v2 proxies in
transparent mode to intercept traffic from servers to the outside
(access control).
The technical solution for this is roughly as follows:
[server] -> [gateway] -> [firewall]
|
----------- DNAT ---------
v
[squid] -> [gateway] -> [firewall] -> [internet router]
this is a bad configuration. The firewall in the path should NOT use DNAT,
since it makes the important part of connection (destination IP) invisible
to squid.
Because squid v2 is becoming more and more obsolete we are looking at
upgrading it towards squid v3.
From what I read in the manuals, transparent mode is replaced by
intercept (and tproxy) mode. But both dont seem to be fully backward
complaint with the v2 transparent mode.
not replaced, but renamed.
A "transparent proxy" is a proxy that does not modify the request or
response beyond what is required for proxy authentication and
identification.
An intercepting proxy is a proxy that intercepts request sent to other
server and handles it by itself.
otherwise the functionality is the same (just better) with intercept.
tproxy is intercepting in special mode, so the connection comes from the
client's instead of proxy server's IP address.
The old trasparent mode allowed us to just dnat traffic towards the
squid host without the need for the client to be aware of this. For
example, the old style accepted 'GET / HTTP/1.1' (without full URL in
the GET request and looking at the Host header for the destination).
The new intercept mode comes close to this behavior, but instead of
remotly dnat, it wants us to next-hop it towards the squid proxy and
redirect it locally. This is problematic for us as firewall and squid
proxy dont live in the same vlan, so next-hop should be the router to
that vlan (and forgetting about the path back to the server). Secondly,
and not less blocking, we use vservers (predecessor to linux containers
lxc) as such, we dont have any promiscuous interfaces rights within the
container.
if you really need to intercept users' requests, your network architecture
should be able to do it.
Is there still a option to emulate normal 'regular´ style squid (as
without any listen options) but instead accepting the URI path in the
GET request and looking at the Host header for the destination? (lets
call it passthrough mode?).
Have you tried configuring WPAD?
Or, is there in squid3 a new and better way to facilitate larger setups,
with the knowledge the server, firewall and squids are all in different
vlans (and no, we dont have Cisco firewalls in between them ;-)).
I am not sure whether it's a good design to intercept requests on one router
and direct them through multiple routers/firewalls.
--
Matus UHLAR - fantomas, uhlar@xxxxxxxxxxx ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Enter any 12-digit prime number to continue.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
