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_at_cache:~# echo $( cat /proc/sys/net/netfilter/nf_conntrack_count ) / $(
> cat /proc/sys/net/netfilter/nf_conntrack_max )
> 351452 / 524288
> root_at_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
Received on Sat Oct 12 2013 - 01:33:34 MDT
This archive was generated by hypermail 2.2.0 : Sun Oct 13 2013 - 12:00:05 MDT