Hi Matus, On 30-09-16 12:36, Matus UHLAR - fantomas wrote: > 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. > That is where the HTTP Host header can be used for... For squid to figure out the destination of the request. (aren´t they?) >> 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. > Sorry, this is a discussion about the definition about what a transparent proxy is and what is not. I dont feel the need for this to discuss at the moment (no hard feelings, but it doesn't aid to the problem i`m facing). >> 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. > Our network architecture is able to do it, otherwise it wouldn't currently work. >> 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? > Linux (shell) servers dont do 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. > The whole idea about intercepting is that we delivered environments in the past (10+ years) who didn't had to be configured to use a proxy. Whatever this was a good thing to do or not is not within my power to change anymore. Back then, SSL wasn't a thing yet. So nobody thought about it. In my reply to Eliezer Croitoru is a network diagram included. Maybe this can shed a light onto our network topology. -- Henry Paulissen - PD0OM henry@xxxxxxxxxxxxxxxx - Phone: +31-(0)6-115.305.64 Linux/Unix System Engineer
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
