On 09.08.2012 08:38, Davide Alberani wrote:
Hi,
I'm trying squid 3.2 (since I'll need some of the new features), but
I'm
having troubles using it in intercept mode, when used along with an
upstream
proxy.
Which 3.2 release number please? that matters a LOT.
Requests are forwarded to squid, but never sent to the upstream
proxy;
using squid directly (setting it into the browser), the requests are
forwarded
to the upstream.
Releases 3.2.0.14->3.2.0.18 have a standing block preventing requests
with conflicting destination IP and destination domain name being passed
to peers.
Release 3.2.0.19 loosens that block to allow it, but only if the
clients original destination IP (ORIGINAL_DST) is non-contactable by the
proxy.
BUT, ... checking your config file there is a bigger problem, and a
relatively large amount of useless ACL checks ...
Notice that I'm sure enough that my iptables rules are correct, and
that
the upstream proxy is correctly configured (simply, there's no
traffic to it,
when squid is used in transparent mode).
Using the same configuration with squid 3.1, also the requests
handled
in intercept mode are forwarded to the upstream.
Any idea? Thanks!
These are the more meaningful parts of the configuration:
==========================================
http_port 172.30.0.16:18080 intercept
http_port 0.0.0.0:8080
server_persistent_connections off
half_closed_clients off
forwarded_for on
acl from_all src all
NP: "all" is a built-in ACL with identical definition to your
"from_all".
acl to_all dst all
acl from_localhost src 127.0.0.1/32
acl CONNECT method CONNECT
acl to_http_port port 80
acl to_proxy_port port 8080
acl to_internal_network dst 172.30.0.16
cache deny from_localhost
cache deny CONNECT
CONNECT requests are never cacheable. You can remove the above line.
cache allow from_all
http_access allow from_localhost
http_access deny to_internal_network to_proxy_port
http_access deny from_all
"deny from_all" being an alias for "deny all" the FAQ comments about
use of "deny all" are relevant here..
FAQ #1: any sequence of deny lines followed by a "deny all" can be
collapsed down into a single ACL line "deny all".
What your config actually tells Squid to do:
http_access allow from_localhost
http_access deny all
http_reply_access allow from_localhost
http_reply_access deny from_all
see above.
What your config actually tells Squid to do:
http_reply_access allow from_localhost
http_reply_access deny all
Additionally. In order for a request to have been accepted by Squid for
processing the http_access rules MUST have accepted it.
Meaning these http_reply_access checks are 100% redundant and can be
removed.
visible_hostname off
# Dansguardian or an upstream proxy.
cache_peer 127.0.0.1 parent 9999 0 no-query no-digest
no-netdb-exchange name=default login=*:password
cache_peer_access default deny from_localhost
cache_peer_access default deny from_all
see above at http_access.
What your config actually tells Squid to do:
cache_peer_access default deny all
Now, you were wondering why the peer got no requests? that would be
why.
Remembering that "from_localhost" is the only traffic which is
permitted into Squid. What exactly are you wanting to be passed to the
parent?
In 3.2 the default action when no cache_peer_access at all is
configured, is to attempt to use the peer.
never_direct deny from_localhost
never_direct allow from_all
Given that from_localhost is the only traffic permitted through Squid
at all. And that "never_direct deny" means "don't restrict". These
never_direct lines are as redundant as the http_reply_access ones and
can be erased.
==========================================
When used in intercept mode, squid handles the request by itself:
==> /var/log/squid/cache.log <==
2012/08/06 13:01:46.477 kid1| forward.cc(273) fwdStart:
'http://www.cnn.com/'
2012/08/06 13:01:46.477 kid1| forward.cc(101) FwdState: Forwarding
client request local=157.166.255.18:80 remote=172.30.0.252:44700 FD
68
flags=33, url=http://www.cnn.com/
2012/08/06 13:01:46.478 kid1| forward.cc(160)
selectPeerForIntercepted: opening a new conn: local=0.0.0.0
remote=157.166.255.18:80 flags=1
2012/08/06 13:01:46.478 kid1| forward.cc(317) startConnectionOrFail:
http://www.cnn.com/
2012/08/06 13:01:46.478 kid1| fwdConnectStart: http://www.cnn.com/
2012/08/06 13:01:46.478 kid1| fwdConnectStart: got outgoing addr
0.0.0.0, tos 0, netfilter mark 0
2012/08/06 13:01:46.478 kid1| The AsyncCall fwdConnectDoneWrapper
constructed, this=0xb81354a8 [call5533]
On the other hand, when set in the browser, the upstream is also
used:
Aug 6 13:04:25 myname (squid-1): 1344251065.036 301 172.30.0.252
TCP_MISS/200 2565 GET http://www.cnn.com/ - FIRSTUP_PARENT/127.0.0.1
text/html
That is very strange. Because your config clearly states "deny
from_all" to that peer.
Maybe we have a bug in FIRSTUP_PARENT selection not checking the
cache_peer_access properly.
Amos
