Re: [squid-users] tproxy and cache_peer

On 11/05/2012 12:42 a.m., Lucas Diaz wrote:
> This config repeats for all the workers on the frontend
>
> if ${process_number} = 1
> cache_peer 172.16.10.69 parent 3150 3250 htcp no-tproxy
> cache_peer_access 172.16.10.69 deny no_proxy2
> cache_peer_access 172.16.10.69 allow streaming_allow_url
> cache_peer_access 172.16.10.69 deny all
> cache_peer 172.16.10.73 parent 3151 3251 htcp no-tproxy
> cache_peer_access 172.16.10.73 deny no_proxy
> cache_peer_access 172.16.10.73 deny streaming_allow_url
> cache_peer_access 172.16.10.73 deny videocache_method videocache_allow_url
> cache_peer_access 172.16.10.73 allow www_bulk
> cache_peer_access 172.16.10.73 deny all
> htcp_port 3351
> endif
>
> The peer 172.16.10.69 is the same for all, and the other peer changes
> from worker to worker. The peer 172.16.10.69 (the backend) also has a
> rewriter for a few URLs.
> The thing is that if I use the proxy frontend in a manual way (ie.
> configuring my browser), it works, I mean, it sends the traffic to the
> parent with the rewriter. On the other hand, if I intercept the
> traffic on this frontend (which is also a router) with tproxy, it stop
> working. All this using 3.2.0.13 or above.
>
> With 3.2.0.7 it works either way, manual on with tproxy.
>
> The config files are exactly the same for both versions, 3.2.0.7 and
> 3.2.0.13. Both proxy frontends are running in the same machine; I stop
> one and try with the other and so on.
>
> Thanks.
>

I'm suspecting this is relatesd to the Host header validation and
forgery detection added about .10.

Please try the 3.2.0.17 snapshot with revision of r11557 or higher. If
the problems remains, please check frontend cache.log entries about Host
header and frontend access.log entries for what TCP_* status codes
happen for those requests.

Amos
Received on Thu May 10 2012 - 15:47:01 MDT