> Hi list,
>
> I have been struggling with this problem for five days now, consulted the
> FAQ's, the example and lots of Google, but I seem to be missing something
> and was hoping somebody would be able to point me in the right direction.
>
> I am trying to use Squid as reverse proxy in our DMZ for several servers
> on the inside. What I have build so far is this:
>
> Internet------firewall-----Squid-----firewall-----internal servers
>
> The problem I am facing is the following error message I get when
> accessing from the outside world.
>
> The requested URL could not be retrieved
> ________________________________________
> While trying to retrieve the URL: /
> The following error was encountered:
> * Invalid URL
> Some aspect of the requested URL is incorrect. Possible problems:
> * Missing or incorrect access protocol (should be `http://'' or
> similar)
> * Missing hostname
> * Illegal double-escape in the URL-Path
> * Illegal character in hostname; underscores are not allowed
>
> I have connectivity from outside to Squid (hence the above message), the
> Squid box can talk to both the inside servers and the outside world, DNS
> is working correctly (both inside and outside), and the inside servers can
> reach the Squid box. Now the strange thing is that when accessing Squid
> from the inside, I also get this message.
>
> Please find my config below.
>
> ======================================================================================================================
>
> ssl_unclean_shutdown on
>
> # Squid luistert op...
> #
> http_port 80 accel defaultsite=www.meandermc.nl vhost
>
> # interne BackendServers definieeren
>
> # cache_peer op SSL
>
>
> # Server 3 webserver
>
> cache_peer 10.32.31.114 parent 80 0 no-query originserver login=PASS
> name=vhost3
> acl vhost3_domains dstdomain kiwiextern.meandermc.nl
> cache_peer_access vhost3 allow vhost3_domains
> http_access allow vhost3_domains
>
Good. But...
what peers are meant to handle request for www.meandermc.nl or other
sub-domains?
A: they get handled as if it was a regular forward-proxy request by the
following controls:
I've cut-n-pasted a few to make it clearer when they are tested.
> acl webserver dst 10.32.31.114
... if a client was requesting data from 10.32.31.114 we'd never see it here.
> acl manager proto cache_object
> acl local src 10.0.0.0/255.0.0.0
>
> # Port ACL
>
>
> acl Safe_ports port 80 443 1494 2598 # http
> acl SSL_ports port 443 1494 2598 # https
Chances are, people people going to your reverse-proxy will only be able
to request port 80 on it. Unless they configure your apparent *web server*
name in their browser proxy settings. Then you have bigger problems.
> acl purge method PURGE
> acl CONNECT method CONNECT
>
> # http access
>
> http_access allow CONNECT SSL_ports
> http_access allow CONNECT Safe_ports
> http_access deny CONNECT !SSL_ports
This third line obsoletes the ones above it.
You shoudl only be using it, unless you actually WANT people being allowed
to make uncontrolled CONNECT tunnels to your proxied web server port 80.
> http_access allow localhost
> http_access allow manager localhost
> http_access allow webserver
see comment where this ACL was defined.
> http_access allow url_allow
Well, you never defined this, so I assume there are parts of the config
you are hiding.
> http_access allow SSL_ports
> http_access deny !Safe_ports
> http_access deny !SSL_ports
These lines above are obsoleted by the one below.
> http_access deny all
> http_access deny manager
and this one obsoleted by the one above it.
> miss_access allow all
Good.
The following are useless, they can be deleted.
> miss_access allow webserver
> miss_access deny all
> never_direct allow all
This means that no requests are allowed to go to peers!!!
>
> #geen Cacheing
> no_cache deny all
This means cache nothing. Even if allowed to.
'no_cache' is deprecated as it was confusing.
text config should be: "cache deny all"
>
> visible_hostname portal.meandermc.nl
> deny_info TCP_RESET all
This "den_info" means any error at all close the connection without saying
why. So... your "miss_access deny all" will generate a reset instead of
"access denied" page.
I'd advise testing without this. Turning it on only for live usage when
you are satisfied squid is working properly.
>
>
> #timeout en error handling
>
> retry_on_error on
> read_timeout 15 minutes
> half_closed_clients off
> memory_pools on
> positive_dns_ttl 24 hours
> negative_dns_ttl 30 seconds
These DNS entries are not recomended, you should have DNS behaving
properly without needing these hacks.
> request_timeout 60 seconds
> connect_timeout 4 hours
> pconn_timeout 4 hours
> ie_refresh on
> emulate_httpd_log off
> log_ip_on_direct on
>
On the whole I believe you should setup a cache_peer line for each of the
proxied servers, and pass requests to it properly instead of relying on a
complicated forward-proxy access control list.
Amos
Received on Wed Sep 24 2008 - 03:39:57 MDT
This archive was generated by hypermail 2.2.0 : Wed Sep 24 2008 - 12:00:03 MDT