Re: [squid-users] Destination address rewriting for TPROXY

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_at_opendium.com
    Email:            steve_at_opendium.com
    Phone:            sip:steve_at_opendium.com
Sales / enquiries contacts:
    Email:            sales_at_opendium.com
    Phone:            +44-844-9791439 / sip:sales_at_opendium.com
Support contacts:
    Email:            support_at_opendium.com
    Phone:            +44-844-4844916 / sip:support_at_opendium.com