On 11/05/2012 7:07 a.m., Lucas Diaz wrote:
> I've got the same results with r11557.
> The cache.log shows nothing about Host header.
> I attached to you the access.log. The entries with source 10.10.10.10
> are with tproxy. The entries with source 192.168.0.10 are the one with
> the proxy manual on the browser.
> The strange thing is that tproxy is actually working, since I can surf
> Internet through the proxy, but can't access to the parent.
> Do you think updating the parent too will do any difference?
No it wont help.
The logged "ORIGINAL_DST" means the domain listed in the Host: header
does not match the IP address of the TCP connection from browser to some
machine X. The Host domain name was looked up and came back to a
completely different set of IP addresses excluding "X". The reasons why
this happens and what you can do to avoid it are outlined at
http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery
In order to preserve both security assumptions made by the browser, CDN
traffic management, and your other users against poisoning attacks. Your
Squid uses the original IP the browser "knows" about as the place it
connected to.
NP: the "no-tproxy" option on cache_peer can only work when its safe to
pass the request to the peer in the first place, and just disabes the
spoofing part of tproxy.
I am working towards plans to re-enable peer relaying but it has to be
done carefully and is not yet finished.
Amos
Received on Fri May 11 2012 - 02:50:45 MDT
This archive was generated by hypermail 2.2.0 : Fri May 11 2012 - 12:00:03 MDT