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_at_ericsson.com . 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
Received on Tue Mar 15 2011 - 22:48:04 MDT
This archive was generated by hypermail 2.2.0 : Wed Mar 16 2011 - 12:00:03 MDT