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
