On 29.05.2012 08:13, Eliezer Croitoru wrote:
hey there Hans,
are you serving squid on the same machine as the gateway is?(wasnt
sure about the DNAT).
your problem is not directly related to squid but to the way that tcp
and browsers works.
for every connection that the client browser uses exist a tcp windows
that stays alive for a period of time after the page was served.
this will cause to all the connections that was served using port
3128 to still exist for i think 5 till 10 more minutes or whatever is
your tcp stack settings.
While that is true for the TCP details I think HTTP connection
behaviour is why that matters. For the TCP timeouts closure to start
happening HTTP has to first stop using the connection.
iptables NAT only affects SYN packets (ie new connections). So any
existing TCP connections made by HTTP WILL continue to operate despite
any changes to NAT rules.
HTTP persistent connections, CONNECT tunnels and HTTP "streaming"/large
objects have no fixed lifetime and several minutes for idle timeout. It
is quite common to see client TCP connections lasting whole hours or
days with HTTP traffic flow throughout.
On 28/05/2012 22:34, Hans Musil wrote:
Hi,
my box is running on Debian Sqeeze, which uses SQUID version
2.7.STABLE9, but my problem also seems to affect SQUID version 3.1.
These are the importend lines from my squid.conf:
http_port 3128 transparent
http_port 3129 transparent
url_rewrite_program /etc/squid/url_rewrite.php
First, I did configure my Linux iptables like this:
# Generated by iptables-save v1.4.8 on Mon May 28 21:04:09 2012
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT
--to-destination 10.17.0.1:3128
COMMIT
and everything works fine.
But when I change the redirect port in the iptables settings from
3128 to 3129, Squid behaves strange: My URL rewrite program still gets
send myport=3128, althought there is definitely no more request on
this port, but only on 3129. This only affects HTTP domains that
already have been requested before, i.e. with redirection to port
3128, and it works fine again when I do a force-reload on my browser.
Also, things turn well when waiting some minutes.
I suppose there is some strange caching inside Squid that maps the
HTTP domain to an incoming port.
No. There is only an active TCP connection. Multiple HTTP request can
arrive on the connection long after you start sending unrelated new
connections+requests through other ports.
What your helper was passed is the details about the request Squid
received. It arrived on a TCP connection which was accepted through
Squid port 3128. The fact that you changed the kernel settings after
that connection was setup and operating is irrelevant.
URL-rewriting is a form of NAT on the URL, but with far worse
side-effects than IP-layer NAT and is often a sign of major design
mistakes somewhere in the network. Why do you have to re-write in the
first place? perhapse we could point you at a simpler more standards
compliant setup.
Amos
