On 7/29/2012 2:21 AM, Ming-Ching Tiew wrote:
From: Eliezer Croitoru <elie...@ngtech.co.il>
To: squid-users@squid-cache.org
now that you remind me.
i have seen this kind of problem!!!
it was nasty on squid 3.1.
you can see in iptables connection tracking that squid is opening the
socket but it sends the first syn and wont get the incoming syn from the
destination.
but there are two different situations bridge and routing.
on bridge it's pretty obviates.
you must tell the bridge to "drop" the incoming traffic from of source
port 8080 otherwise it will be bridged to the client and wont get back
to squid.
If it is an external web server, the ebtable rule will probably fix it.
But for my case, on the squid machine, I have a web server, and
the url rewrite redirect the traffic to this web server. And I don't seem
to be able to get a reply back into squid. Which is blocking the reply
?
This is a problem with + tproxy and servers that hosts a webserver on
the same machine.
it seems like when squid on tproxy mode it opens a Socket to the origin
server and since it's on the same machine the routing on the machine
main routing table is to send it strait to the client machine without
intercepting\redirecting it into the lookback\squid.
the simple solution for that is to use cache_peer to port 8080 and use
acls to apply the rewritten request through the cache_peer remember to
add the cache_peer "no-tproxy" option.
if there was an option\acl "no-tproxy alllow acl_name" this would give
some nice option but since it's not needed for most of the users i dont
thing it will be implemented.
Regards,
Eliezr
--
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
