On 03/12/13 04:01, Amos Jeffries wrote:
Does the patch from http://bugs.squid-cache.org/show_bug.cgi?id=3589 fix
this for you?
Thanks for the reply... The answer is yes and no. :)
The patch causes Squid to connect to the right place, but it appears
that the ACLs don't necessarilly get re-evaluated.
The relevant chunk of my Squid config is:
-----
# cache_peer for the local webserver to prevent t-proxy spoofing of
requests to localhost
cache_peer [::1] parent 80 0 proxy-only no-query no-digest no-tproxy
originserver name=localhost_80
cache_peer_access localhost_80 deny !port_80
cache_peer_access localhost_80 allow to_localhost
cache_peer_access localhost_80 deny all
cache_peer [::1] parent 3129 0 proxy-only no-query no-digest no-tproxy
name=caching
cache_peer_access caching deny to_localhost
cache_peer_access caching deny CONNECT
cache_peer_access caching deny https
cache_peer_access caching deny tproxy_ssl
cache_peer_access caching allow all
adaptation_access iceni_respmod deny to_localhost
adaptation_access iceni_respmod allow all
-----
During REQMOD, the ICAP server decides whether or not the web request
should be blocked. For unblocked requests it either loops back the
request unaltered or returns a 204. For blocked requests, it rewrites
the request to go to http://localhost/blah and the local webserver does
the heavy lifting of presenting an error page to the user.
The cache_peer and cache_peer_access lines should cause Squid to send
the http://localhost/blah requests directly to the local web server
without tproxy spoofing, all other HTTP traffic goes via an upstream
caching proxy.
The adaption_access line should prevent the http://localhost/blah
requests going through the ICAP RESPMOD service.
However, the to_localhost ACL doesn't seem to be working. The rewritten
requests are still being sent through RESPMOD and the upstream proxy
when the system is used as a transparent proxy, even though this works
correctly for non-transparent proxying.
Replacing the to_localhost ACL with one that checks dstdomain =
localhost works as expected, so this is a reasonable stop-gap, but it
does seem that to_localhost is behaving in an unexpected way, since its
behaviour changes depending on whether the proxy is transparent or not.
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com
Direct contacts:
Instant messager: xmpp:steve@xxxxxxxxxxxx
Email: steve@xxxxxxxxxxxx
Phone: sip:steve@xxxxxxxxxxxx
Sales / enquiries contacts:
Email: sales@xxxxxxxxxxxx
Phone: +44-844-9791439 / sip:sales@xxxxxxxxxxxx
Support contacts:
Email: support@xxxxxxxxxxxx
Phone: +44-844-4844916 / sip:support@xxxxxxxxxxxx
