On 11/10/2013 11:50 p.m., Omid Kosari wrote:
> First of all thanks for professional comments about configs . i was looking
> for that
>
>
> Amos Jeffries-2 wrote
>> Possibly the URL-rewriter. Depending on whether it is rewriting URLs to
>> point anywhere back at this proxy.
> my jesred.rules contains
>
> regexi ^http://(.+\.||)server.cn/.*
> 302:http://www.netshahr.com/website-unavailable/
> regexi ^http://cpe.management/.*
> 302:http://www.netshahr.com/website-unavailable/
> regexi ^http://wpad.domain.name/.*
> 302:http://www.netshahr.com/website-unavailable/
> regexi ^http://isatap.home/.*
> 302:http://www.netshahr.com/website-unavailable/
> regexi ^http://(.+\.||)scorecardresearch.com/.*
> 302:http://www.netshahr.com/website-unavailable/
Would your proxy happen to be receiving the inbound traffic to
www.netshahr.com port 80 ?
> Amos Jeffries-2 wrote
>> Also, Squid serves some content directly. Such as embeded objects in
>> error pages, icons on FTP listing pages, cachemgr reports, cache peer
>> communications. These require a regular forward-proxy http_port without
>> intercept/tproxy options. Requests for these are being rejected by your
>> config (to_mysef ACL) but will also get these NAT failures first.
> But these rules existed before and that problem did not occur . BTW i
> commented those 2 lines to see what happens
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.
> Amos Jeffries-2 wrote
>> What version of Squid are you using? 3.2 and later will silence the
>> above problem most of the time but it is still corrupting your logs.
> Sorry forgot to say .
> Ubuntu Linux 12.10 x86_64 squid 3.1.20-1ubuntu1.1 . packages are default
> ubuntu packages .
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.
> Amos Jeffries-2 wrote
>> Please run "squid -k parse" over this config and fix anything it
>> highlights.
> Highlights ?! you mean Warnings ? only following warnings appears after your
> comments done . a bit explain please .
>
> 2013/10/11 13:46:12| WARNING: use of 'ignore-reload' in 'refresh_pattern'
> violates HTTP
> 2013/10/11 13:46:12| WARNING: use of 'ignore-no-cache' in 'refresh_pattern'
> violates HTTP
> 2013/10/11 13:46:12| WARNING: use of 'ignore-no-store' in 'refresh_pattern'
> violates HTTP
> 2013/10/11 13:46:12| WARNING: use of 'ignore-private' in 'refresh_pattern'
> violates HTTP
> 2013/10/11 13:46:12| WARNING: HTTP requires the use of Via
Well, anything about directives needing to be updated or replaced.
Sometimes it can highlight ERROR's. Though with 3.1 its of limited use,
the later versions are a lot more informative.
> Amos Jeffries-2 wrote
>> So what is the objection to via?
>>
>> Note that the special access controls you have to use to avoid the
>> probems removing it is causing will not prevent relay loops which happen
>> as 2-hop loops via the peer and will break the URLs being served up
>> directly by this proxy.
> Tried to hide the proxy as possible . you suggest turn it on ?
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.
Amos
Received on Fri Oct 11 2013 - 12:08:43 MDT
This archive was generated by hypermail 2.2.0 : Fri Oct 11 2013 - 12:00:04 MDT