Re: [squid-users] squid 3.2 intercept and upstream proxy not working

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
Received on Wed Aug 08 2012 - 23:16:38 MDT