On 29/05/2013 8:32 p.m., marius buz wrote:
> Hello.
>
> At work I "inherited" a Linux box router, Fedora Core 6, firewall with iptables 1.3.8 and squid 2.6.STABLE13.
> I decided it's time to move on and installed a new box, with Fedora Core 18, firewall with iptables 1.4.16.2 and squid 3.2.9.
> Didn't had any complaints until yesterday when accounting dept. told me one site it's not loading anymore: http://www.bnro.ro which redirects to
> http://www.bnro.ro/Home.aspx
> It's the site of our national bank and contains relevant data for them. Any other sites with .aspx are loading just fine. I was puzzled so I decided to shutdown squid and stop redirecting packets to it. Surprise, the site began to load.
> My problem is: why the old server with squid didn't had any issue with this .aspx page and the new one has ?
> I'm pasting below the squid.conf files from the old and the new server, maybe (for sure) I missed some settings.
With your new Squid pelase rune "squid -k parse". It will highlight a
few things in your config file which have changed since 2.6 and need
fixing to work properly in your version.
I have mentioned a few below which may not be highlighted by 3.2.
> OLD server (XXX instead sensitive data)
>
> http_port 10.0.0.1:8081 transparent
> logformat acclog %tl %>a %Ss/%Sh/%03Hs %rm %ru %<A
> cache_mgr XXX
> cache_dir ufs /var/cache/squid 256 16 128
> logfile_rotate 2
> cache_access_log /var/log/squid/cache_acces_log acclog
> cache_store_log none
> cache_mem 64 MB
> emulate_httpd_log on
> cache_vary off
> maximum_object_size 10 MB
> maximum_object_size_in_memory 32 KB
> max_filedesc 4096
> log_icp_queries off
> forwarded_for off
> visible_hostname XXX
> debug_options ALL,1 28,2 82,2
>
> acl all src 10.0.0.0/24
NOTE: this is one major difference between the old and new servers. The
old server "all" was being completely redefined as this 10/8 which means
that a lot of security checks, limits and other things all over the code
which depended in "all" ACL were blocking or limiting 10/8 and *not*
affecting any other traffic. Potentially huge security holes or traffic
bypassing protections and control points.
The new version will rightly reject such a dangerous thing (I see you
removed the "all" definition there), and your new proxy behaviour will
be subtly different just because of all the traffic which is now
behaving better.
> acl manager proto cache_object
> acl localhost src 127.0.0.1/255.255.255.255
> acl to_localhost dst 127.0.0.0/8
> acl SSL_ports port 443 563
> acl Safe_ports port 80 # http
> acl Safe_ports port 443 563 # https, snews
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
>
> acl purge method PURGE
> acl CONNECT method CONNECT
>
> acl denied_domains dstdomain -i "/etc/squid/denied_domains.acl"
> acl denied src "/etc/squid/denied_range.acl"
>
> # Allow localhost to manage the cache
> http_access allow manager localhost
> http_access deny manager
> # Allow localhots to purge the cache
> http_access allow purge localhost
> http_access deny purge
> # Deny all ports except those mentioned as safe-ports
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> # Allow access to use Squid from localhost
> http_access allow localhost
> # Custom rules
> http_access deny denied denied_domains
>
> NEW server (XXX instead sensitive data)
>
> http_port 10.0.0.1:8081 intercept
> logformat acclog %tl %>a %Ss/%Sh/%03>Hs %rm %ru %<A
> cache_mgr XXX
> cache_effective_user squid
> cache_effective_group squid
> cache_dir ufs /var/cache/squid 256 16 128
> logfile_rotate 2
> cache_access_log stdio:/var/log/squid/cache_acces_log acclog
The name is "access_log" drop the "cache_" part.
> cache_store_log none
You can remove cache_store_log entirely from your config.
> cache_mem 64 MB
> negative_ttl 1 minute
> maximum_object_size 10 MB
> maximum_object_size_in_memory 100 KB
> max_filedescriptors 0
> log_icp_queries off
> forwarded_for off
> visible_hostname XXX
> debug_options ALL,1 28,2 80,2 82,2
> httpd_suppress_version_string on
> client_persistent_connections on
> server_persistent_connections on
These are now the defaults. You can remove teh above two lines entirely.
> acl SSL_ports port 443 563
> acl Safe_ports port 80 # http
> acl Safe_ports port 443 563 # https, snews
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl purge method PURGE
> acl CONNECT method CONNECT
>
> acl denied_domains dstdomain -i "/etc/squid/denied_domains.acl"
> acl denied src "/etc/squid/denied_range.acl"
> acl url_ads url_regex -i "/etc/squid/denied_ads.acl"
> acl spam dst "/etc/squid/spam.acl"
> acl domain_ads dstdom_regex -i "/etc/squid/ads.acl"
> acl NoProxy urlpath_regex -i cgi-bin/nph-.*/ nph-proxy\.cgi cgiproxy
> acl NoProxyIP dst "/etc/squid/proxies.acl"
> acl seara time MTWHFAS 19:00-23:59
> acl noaptea time MTWHFAS 00:00-07:00
>
> ***#refresh_pattern -i \.(asp|aspx)(\?.*)?$ 0 20% 6000 override-expire override-lastmod ignore-private ignore-reload
> ***refresh_pattern .aspx 0 0% 0
> ***refresh_pattern .asp 0 0% 0
If the URL is not even loading these will not help. That refresh_pattern
is about cacheability freshness of already cached content.
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern . 0 20% 4320
>
> # Allow localhost to manage the cache
> http_access allow localhost manager
> http_access deny manager
> # Allow localhots to purge the cache
> http_access allow purge localhost
> http_access deny purge
> # Deny all ports except those mentioned as safe-ports
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> # Allow access to use Squid from localhost
> http_access allow localhost
> # Custom rules
> http_reply_access deny denied denied_domains
> http_access deny denied denied_domains
> http_access deny url_ads
> http_access deny domain_ads
> http_access deny spam
> http_access deny CONNECT denied_domains denied
You already blocked clients from making requests for "denied_domains
denied" for all request types - including CONNECT.
So this CONNECT line is not matching anything that gets to check it.
Also, the http_reply_access line for "denied_domains denied" is just
blocking the http_access request-rejected message/page and replacing it
with a reply-rejected message/page. Which is a bit odd because it was
the request which was actually rejected.
> http_access deny denied NoProxy seara
> http_access deny denied NoProxyIP seara
> http_access deny denied NoProxy noaptea
> http_access deny denied NoProxyIP noaptea
>
> As you can see, the acls are pretty much the same, my guess the problem is with refresh_pattern. I have tried different approaches, see lines with ***. All other
> pages with .aspx are loading, http://www.bnro.ro/Home.aspx doesn't load.
> Advices from here http://www.squid-cache.org/mail-archive/squid-users/201001/0398.html still don't fix the problem.
> Could be because of this: http://support.microsoft.com/?scid=kb%3Ben-us%3B841998&x=14&y=9 but all browsers do the same, not only IE.
> Workaround ?
> 1. Do not call the Response.Flush method in the code. It's not up to me.
Exactly. And if its working via non-Squid pathways it is unlikely to be
that. But one never knows.
> 2. Do not go through a server that is running SQUID Proxy Server software. Maybe bypass squid for this site ?
Since it is all intercepted traffic, you coudl bypass the site by
updating the firewall rules. Up to you.
FWIW: There are a *lot* of protocol and feature changes between those
two Squid versions. Any one of those differences could be handled badly
by a sites page code. Or by Squid, but we do usually find it to be
low-quality code crashing on the web server when it receives some new
HTTP feature in the headers.
I have thrown a few tests at it that usually show up the common HTTP/1.1
related problems and the server is doing something very strange which I
have not encountered before. It responds immediately to requests with
"HTTP/1.0" as the protocol format label. But takes 10-15 seconds to even
complete the TCP connect when HTTP/1.1 is sent as the protocol format
specifier. It may be some form of firewall/load balancer in the way
which is depending on the ancient "HTTP/1.0" string being sent. After a
wait it does work though, so you should be seeing something show up.
If you can jump up another version to 3.3.5 you will find a few more bug
fixes in Squid, and somewhat better debugging info. debug_otions 11,2 is
supposed to show the HTTP headers traffic between Squid and the server
(I forget if 3.2 got that, but 3.3 certainly does). That might help you
see what is coming and going (if anything).
Amos
Received on Wed May 29 2013 - 10:31:33 MDT
This archive was generated by hypermail 2.2.0 : Wed May 29 2013 - 12:00:07 MDT