-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 20/04/2014 7:35 a.m., Tobias Krais wrote:
> Hi babajaga,
>
>>> ....HIER_DIRECT/127.0.0.1 ...<
>> Strange enough, squid forwards the request to 127.0.0.1 ....
>
> Is there a possibility to tell squid stop forwarding.
With an "http_access deny" line. The results will not be what you want
though.
Your setup expectations seems to be based on an misunderstanding of
how transparency and interception work together.
To begin with "NAT intercept" is *not* fully transparent. The server
is always completely aware of the proxies existence. Only the client
is kept unaware that it is talking to a proxy and not directly to the
origin server.
I hope the details below will help clarify why that is a critical fact...
(If you want to skip the reasons for things I have a short summary at
the end of this mail.)
>
>> I am not sure, whether you need 2 ports to be specified:
>> http_port 3129 http_port 3128 intercept
>
> I tried it, but it still does not work. Same error. Here my
> current squid.conf: -----%<----- acl SSL_ports port 443 acl
> Safe_ports port 80 # http acl Safe_ports port 21 #
> ftp acl Safe_ports port 443 # https acl Safe_ports port 70
> # gopher acl Safe_ports port 210 # wais acl Safe_ports port
> 1025-65535 # unregistered ports acl Safe_ports port 280 #
> http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports
> port 591 # filemaker acl Safe_ports port 777 #
> multiling http acl CONNECT method CONNECT # http_access deny
> !Safe_ports # http_access deny CONNECT !SSL_ports # http_access
> allow localhost manager # http_access deny manager # http_access
> allow localhost # http_access deny all http_access allow all
> http_port 3127 http_port 3128 intercept coredump_dir
> /var/spool/squid3 refresh_pattern ^ftp: 1440 20%
> 10080 refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern
> (Release|Packages(.gz)*)$ 0 20% 2880 refresh_pattern
> . 0 20% 4320 -----%<-----
>
>> In your setup, you need special firwall rules, to avoid a loop:
>> DG forwards to port 80, squid intercepts, forwards to port 80,
>> NO INTERCEPT THEN (hopefully) So you should post firewall rules,
>> as well.
>
> Here it is: -----%<-----
<snip>
>
> # Fuer folgende Netzwerke braucht es keinen Proxy iptables -t nat
> -A OUTPUT -d 10.0.0.0/8 -j ACCEPT iptables -t nat -A OUTPUT -d
> 192.168.0.0/16 -j ACCEPT iptables -t nat -A OUTPUT -d 127.0.0.1 -j
> ACCEPT
>
<snip>
>
> # Port 80 Traffic automatisch auf Dansguardian legen # Traffic von
> root akzeptieren iptables -t nat -A OUTPUT -p tcp --dport 80 -m
> owner --uid-owner root -j ACCEPT iptables -t nat -A OUTPUT -p tcp
> --dport 80 -m owner --uid-owner proxy -j ACCEPT # ... alle anderen
> Benutzer auf Port 8080 umbiegen iptables -t nat -A OUTPUT -p tcp
> --dport 80 -j REDIRECT --to-port 8080 iptables -t nat -A OUTPUT -p
> udp --dport 80 -j REDIRECT --to-port 8080
NOTE: HTTP does not travel over UDP.
> -----%<----- But even without flushing all rules and setting the
> proxy manually - same error...
Your nat rules are not catching traffic on arrival. They are catching
traffic as it leaves the entire machine. Both DG outbound, and Squid
outbound, and client outbound all mixed up and hitting the same rules.
If I am reading that properly you have configured the following:
client--->(NAT)
\ DG --> (NAT , OUTPUT ACCEPT) -> Internet
Squid [ doing nothing ]
or possibly:
client--->(NAT)
\ Squid --> (NAT, OUTPUT ACCEPT 'proxy') -> Internet
|
DG receiving nothing
>
>> Otherwise: I always did it the other way: client ---
>> (transparent) squid ---DG --web because
NOTE: This is the way a "transparent intercpetion proxy" is seup. You
can choose _either_ Squid or DG to be the front one with
"(transparent)" on it, but not both.
It is setup this way because as I said at the beginning, NAT intercept
is not fully transparent.
* the second proxy in the chain is fully aware of the first proxies
existence. There is no reason to hide the second one from the first.
Doing so will only cause problems - one of which is the looping
problem you are hitting.
>> 1) client does not need to specify proxy explicitly (in your
>> setup, a MUST) 2) no need to cache content, later on blocked by
>> DG 3) Not sure any more, whether DG supports parent proxy
>
> With squid 3.1.20 it works perfectly.
*No it does not*. Squid 3.1 and older just hid the problems it was
causing. I see below that this is all internal to one machine - if
this is a situation like the proxies being installed on an end-user
device then the extra layers of NAT are useless.
If this is a VM server with lots of internal clients, then treat it
as a network and the entire "machine" has been vulnerable to
CVE-2009-0801.
> Thus I think it should work with squid 3.3.8, too. Here the
> relevant part of my dansguardian.conf: -----%<----- # the port that
> DansGuardian listens to. filterport = 8080
>
> # the ip of the proxy (default is the loopback - i.e. this server)
> proxyip = 127.0.0.1
>
> # the port DansGuardian connects to proxy on proxyport = 3128
> -----%<-----
That is fine.
> Dansguardian forwards correctly to squid. The dansguardian part
> works (and blocks) perfectly.
Good. Then there is no reason for "intercept" option to exist in
squid.conf. DG is already explicitly configured to use Squid.
As a result DG outbound traffic is *not* going to port 80 like your
iptables rules suggest, but to port 3128 as a direct forward-proxy
connection.
Like so:
client -> (:80) NAT
\ DG:8080 -> Squid:3128 -> Internet :80
>
>> Then my setup matched the rules in
>> http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect
>
>>
> I read this link also. That is why I made the change from
> "transparent" to "intercept".
>
> My scenario is a bit different from that on the link: client and
> server is the same machine.
>
>> Only the line cache_peer 127.0.0.1 parent DG-port 0 no-query
>> no-digest no-netdb-exchange to be added to squid.conf
>
> Now I added this line at the end of the squid.conf file. But still
> no change.
Given the DG config file above and that entry in Squid...
client -> (:80) NAT
\ DG:8080 -> Squid:3128 /
\-----<------<--/
>
> Do you have any other ideas?
Please map out the network flow diagram you want to see happening.
* NAT can only happen at one place, preferrably the one between client
and whichever proxy is first. In the same OS as the first proxy.
* the first proxy must be configured to use the second as its parent.
With DG first the DG cofig you started with should be fine.
* the second must be a normal forward-proxy configuration. It is
simply accepting requests from the first proxy, nothing special about
that.
* the second proxy must be the one permitted access to the Internet in
your firewall. (by UID as you have should be fine).
In summary,
If I am understanding correctly all you need to do is:
1) go back to the original "working" configuration you started with
using DG and Squid-3.1.
2) remove the "transparent" option on Squid http_port 3128. Do *not*
replace it with anything.
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTU2AwAAoJELJo5wb/XPRj5cIIAJOLNwbDWTzWez7UcQ+9BB1Q
RxlSACeEewaUg0CFIOI8UN1Ryfs3K4BEVllnVx1LzloMl9M61ujtE9rK944UmBJB
LGRz/dzw+acDAYcFoz5HZAgNDcD7JoH6KjuDg75lnnub7vFb7k+bDDCcJIGPypVz
zl7h5tMXCp6Po2r1leP6t04I4JibrEd5GX6BEVzZHcCMPvwiiLGHDN+Tv2bn7epN
Qk1uc7EreLCv0X3RcW1/1/gpgNqDyL8uPEkwhe/FUgHQ2ZCJFF5jbwcyBWkb56Eg
7iP5Wy8n+atpf4oUgMwDPYozN9Wi/gsasoV+3cp+eTw5kumG7/dWMtk06DrGaNc=
=t9do
-----END PGP SIGNATURE-----
Received on Sun Apr 20 2014 - 05:50:47 MDT
This archive was generated by hypermail 2.2.0 : Tue Apr 22 2014 - 12:00:06 MDT