On 12/10/2013 4:48 a.m., Omid Kosari wrote:
Amos Jeffries-2 wrote
Would your proxy happen to be receiving the inbound traffic to
www.netshahr.com port 80 ?
Let answer like this . netshahr.com is one of our customers . customers dst
port 80 will be routed to squid except if dst address is another customer .
so if netshahr.com wants access yahoo.com it goes to squid . but if clients
wants to open netshahr.com it does not goes through squid and vice versa .
Another thing i did not investigate a lot but when i removed 302: from
jesred.rules the redirection does not work and browser waits several minutes
for response .
Okay. Those rules are being applied to all your customers traffic. Not
just the netshar traffic. So non-netshar customers would be redirected
to www.netshahr.com and then your proxy. You may need to add extra src
ACL test to restrict the clients who get the redirect applied - which is
true whether you keep using jesred or siwtch to the squid-only option below.
This is how you do the exact same thing with only Squid instead of using
jesred:
acl domains_to_redirect dstdomain "/etc/squid3/to_redirect_program.acl"
acl netshar_regex url_regex "/etc/squid3/netshar_regex.acl"
deny_info 302:http://www.netshahr.com/website-unavailable/ netshar_regex
adapted_http_access deny domains_to_redirect redirect_regex
/etc/squid3/netshar_regex.acl contiains the regex patterns being checked
by jesred:
^http://(.+\.||)server.cn/
^http://cpe.management/
^http://wpad.domain.name/
^http://isatap.home/
^http://(.+\.||)scorecardresearch.com/
If you need any other redirect destinations you can create other *_regex
ACL and deny_info pairs. Or in the later squid versions use deny_info
pattern substitution to generate the redirect URL
(http://wiki.squid-cache.org/Features/CustomErrors).
Amos Jeffries-2 wrote
I mean a new line above them:
http_port 12345
or whatever you like for the port value. It does not have to be used,
but will help prevent traffic going to the interception ports when it
was not intercepted.
ok got it . i changed it to following lines .
http_port 3127 intercept
http_port 3128
http_port 3129 tproxy
after that following appears in headers
X-Cache MISS from cache.xx.com
X-Cache-Lookup MISS from cache.xx.com:3127
Via 1.0 cache.xx.com (squid)
is the X-Cache-Lookup line ok ? it should show 3127 ?!
This is why I said put the forward-proxy port at the top of the list.
3.1 does not filter out intercept/tproxy ports when it generates those
host:port details. It just uses the first http_port value.
The idea is to hide the intercept/tproxy port details from any possible
kind of external connection directly to them.
Amos Jeffries-2 wrote
Okay. The ORIGINAL_DST security checks are not present in 3.1, so the
NAT error is a non-fatal event for you at the moment. If it is
encountered by a 3.2 or later proxy it is a transaction blocking event.
In 3.1 the NAT lookup is rather strangely done after parsing each HTTP
request, even on persistent connections, so it may just be something
related to NAT table entries expiring while buffered requests are
processed. Or the NAT system being overloaded with useless lookups on a
heavily loaded machine - both those should be kind of rare though.
But it is fatal event for my network :)
root@cache:~# echo $( cat /proc/sys/net/netfilter/nf_conntrack_count ) / $(
cat /proc/sys/net/netfilter/nf_conntrack_max )
351452 / 524288
root@cache:~# grep conntrack /proc/slabinfo | awk '{ SUM += $3 * $4 } END {
print SUM / 1024 / 1024 " MB" }'
109.316 MB
Can you guide me to NOTRACK usefulness conntracks ? for example may i safely
notrack htcp traffic between 2 squid boxes ? what kind of other traffics ? i
hate try and false in production .
conntrack is required for tracking the NAT and TPROXY translations.
You can use it on other traffic, but not on that going to the proxy.
NP: If you have stopped tracking for inbound connections to the proxy it
would probably generate this ORIGINAL_DST error message.
As i said in first post this problem appears after those 3 changes .
problems with nat existed before but this problem appears recently . BTW i
need help to clears unused conntrack .
If you say i can try to upgrade my squid package from
http://packages.ubuntu.com/saucy/squid3 .
Amos Jeffries-2 wrote
It would be worth it for testing this problem at least. If requests were
being looped through the proxy twice having it on will produce a warning
message.
Via turned on sir . but one question . how loop may occur ?
The simplest one is:
GET http://cache.xx.com:3127/ HTTP/1.1
Host: cache.xx.com:3127
or
GET / HTTP/1.1
Host: localhost:3127
client--(squid:3127)-> Squid --(squid:3127)-> Squid <== loop with 2x
NAT lookup error!
Or the NAT/TPROXY rules being configured to turn outbound traffic
leaving your proxy back at at itself:
client --(example.com:80)-> NAT--(squid:3127)-> Squid -> NAT
--(squid:3127)-> Squid <== loop!
client --(example.com:80)-> TPROXY --(squid:3129)-> Squid -> NAT
--(squid:3127)-> Squid <== loop!
client --(example.com:80)-> TPROXY --(squid:3129)-> Squid -> TPROXY
--(squid:3129)-> Squid <== loop!
client --(example.com:80)-> NAT--(squid:3127-> Squid -> TPROXY
--(squid:3129)-> Squid <== loop!
Amos
