On Tue, 15 Mar 2011 11:53:24 -0500, Bill DeGan wrote:
We have been using squid in a reverse proxy mode for several weeks
now
and its been working well.
Lately we have remote users that have a transparent proxy and users
are getting hung when trying to access a particular page.
Going thru cache.log and all I see for every connection is "ALLOWED",
but do see lines line this:
2011/03/15 09:47:20| clientReadBody: start fd=48 body_size=97
in.offset=0 cb=0x450740 req=0x1cf9dd40
2011/03/15 09:47:20| clientProcessBody: start fd=48 body_size=97
in.offset=0 cb=0x450740 req=0x1cf9dd40
2011/03/15 09:47:20| clientProcessBody: start fd=48 body_size=97
in.offset=97 cb=0x450740 req=0x1cf9dd40
2011/03/15 09:47:20| clientProcessBody: end fd=48 size=97 body_size=0
in.offset=0 cb=0x450740 req=0x1cf9dd40
2011/03/15 09:47:20| The reply for POST
http://IP_ADDRESS/services/forward/jcore_security_check is ALLOWED,
because it matched 'all'
That is the *reply* being allowed. Which could be either the error page
reply or the desired successful reply.
"IP_ADDRESS" is likely part of the problem.
An IP address specifies an *exact* individual machine to connect to.
Which is likely either not the reverse proxy, or not the backend web
service.
Transparent proxies use the Host: header. Some cope with it being
missing by using the destination IP and placing that in the Host:
(ouch).
Not sure if clientProcessBody is a problem or not?
No. It is just Squid pumping data from the client to server (97 bytes
of POST data in this case).
Another group wants to replace the squid with Apache reverse proxy
and
tried it out this morning and it didn't have any problems with the
remote user and the downstream proxy server.
Interesting.
Apache Name-based virtual hosting with mod_proxy does the same as what
you appear to have configured in Squid:
an accel vhost port with a URL-rewriter altering what the backend
thinks the client is talking about.
(I am assuming your re-writer is changing the clients public FQDN and
maybe path segments to something the backend(s) can handle).
Here are my squid_conf settings:
auth_param basic program /usr/lib64/squid/ncsa_auth
/etc/squid/squid_passwd
auth_param basic realm Ericsson. For support email
performance@xxxxxxxxxxxx . A login
auth_param basic credentialsttl 1 hours
authenticate_ttl 1 hour
authenticate_ip_ttl 1 hour
external_acl_type mysession ttl=10 children=5 negative_ttl=0 %LOGIN
%PATH /usr/local/bin/ckuser.pl
acl mysession external mysession %LOGIN %PATH
? interesting. Does this pass the text "%LOGIN %PATH" to the helper? or
act like the pattern "%LOGIN %PATH %LOGIN %PATH"?
acl strt1 url_regex [-i] ^http://www.ericssonperformance.com$
acl strt2 url_regex [-i] ^http://129.192.172.19$
acl good_src url_regex -i \.php 129.192.172.19\/$
www.ericssonperformance.com\/$
Interestingly I don't see anywhere these ACL are actually checked.
http_access only allows logged-in users through to the website.
acl all src all
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 443 # https
acl Safe_ports port 1025-65535 # unregistered ports
acl ncsa_users proxy_auth REQUIRED
acl CONNECT method CONNECT
deny_info ERR_ACCESS_DENIED Safe_ports
? ERR_ACCESS_DENIED is the object returned on any http_access "deny" by
default. The above should not be needed at all.
http_access deny !Safe_ports
deny_info ERR_ACCESS_DENIED ncsa_users
? ncsa_users is not used in any "deny" line. The above setting has no
effect.
http_access allow mysession ncsa_users
http_access deny all
http_reply_access allow all
icp_access allow localnet
icp_access deny all
reply_body_max_size 0 allow all
acl_uses_indirect_client on
http_port 10.102.16.101:80 accel defaultsite=129.192.172.19 vhost
defaultsite=* should be the public FQDN for your web service. Probably
defaultsite=www.ericssonperformance.com
This is one of Squid's benefits over Apache. When this works there is
no reason for the url-rewrite part to alter the domain part of URLs.
Only strange backends like Zope that *depend* on Apaches broken
re-writing model actually need re-writers these days.
You may be able to use this trick to avoid raw-IP accesses entirely.
(place just under http_access for Safe_ports):
acl brokenIP dstdomain 129.192.172.19
deny_info http://www.ericssonperformance.com/ brokenIP
http_access deny brokenIP
(This performs a *real* HTTP redirection from http://129.192.172.19/...
to http://www.ericssonperformance.com/
Equivalent to an Apache "ProxyDomain www.ericssonperformance.com"
directive.)
forwarded_for on
cache_peer 10.202.16.117 parent 80 0 no-query
originserver name=ADMIN
cache_peer_access ADMIN allow all
cache_peer 10.202.16.37 parent 80 0 no-query
originserver name=WPP1
cache_peer_access WPP1 allow all
cache_peer 10.202.16.40 parent 80 0 no-query
originserver name=WPP2
cache_peer_access WPP2 allow all
Okay, so everything arriving at Squid is passed to one of the peers
after login is checked. Bit dangerous but okay.
NP: If possible I would list the domains being proxied in a dstdomain
and deny everything else with an http_access.
ie changing the last few http_access lines to:
acl sites dstdomain .ericssonperformance.com
acl sites dstdomain 129.192.172.19 # Only if you must. Avoid where
possible.
http_access allow sites ncsa_users mysession
http_access deny all
hierarchy_stoplist cgi-bin ?
cache_dir null /tmp
access_log /var/log/squid/access.log squid
debug_options ALL,1 33,2
log_fqdn off
url_rewrite_program /usr/local/bin/rewrite.pl
url_rewrite_children 20
url_rewrite_concurrency 0
url_rewrite_host_header on
redirector_bypass off
location_rewrite_program /usr/local/bin/rewrite.pl
Some of the results come down to what these helpers are doing to the
URLs.
<snip>
Amos
