RE: FW: [squid-users] reverse proxy

Thanks again Darryl,

I have looked at the httpd_accel_host virtual option, but figured this
only worked for single backend servers. Which is why I figured it should
work as a standard proxy for a small number of 'public sites'. Just
whack it in backwards huh? Should do the trick!

Our application servers don't have public ip's we have a single public
on our firewall and everything else is private. I had a look at the
redirect_rewrites_host_header and figured I definitely didn't want that!

She certainly is a powerful beast, but some parts of the config seem
sparse in their purpose definition - or maybe it's just me?

The function I most want is the proxying, as redirection will cause the
return traffic to go via the firewall directly and all will break.

Will give the uses_host_headers a crack. It looks like it should do the
job! It was the single ip that made the host header a requirement. Just
more of a pain when going to multiple servers rather than sites on a
single box.

Thanks for your input, it has been greatly appreciated.

John

-----Original Message-----
From: Darryl L. Miles [mailto:darryl@netbauds.net]
Sent: Tuesday, 16 August 2005 8:27 p.m.
To: John Rooney
Cc: squid-users@squid-cache.org
Subject: Re: FW: [squid-users] reverse proxy

John Rooney wrote:

>The firewall provides NAT translation and forwards the http traffic to
>the squid proxy.
>
>What I'm doing is putting the Squid into a DMZ and trying to use proxy
>facilities to host the internal boxes. That way only the squid is able
>to be compromised. So there is a mix of general web http traffic and
>some with ntlm or chap authentication.
>
>
This NTLM and CHAP authentication is for your customer/client base to
access your application servers.

>The features I'm wanting fall neatly outside of both definitions you
>supplied, as it is purely to isolate our production application
servers.
>All inbound traffic hits the squid and using host headers to identify
>the appropriate internal server. Proxies the connection to the right
>one. Nothing to do with load balancing or acceleration, and not an
>outbound function. Which is why I refer to it as a reverse proxy.
>
>
>
Understood in what you are saying. Your usage is very solidly what
squid terms HTTP accelerator. You are fronting websites not providing a

shared cache for a browser client network.

Recommendations:

* Ensure that the squid box can use DNS to hit each of the different
target application servers.
* Check out the "http_accel_host virtual", squid has two basic mode of
operation, fixed backend application server IP address or work it out
from the inbound customers Host: header (virtual).
* If you want apache style log output for full analysis of the real hits

you are taking, then checkout the patch at
http://devel.squid-cache.org/customlog/

* Config may look something like this:

http_port 123.123.123.112:8581
acl services dst 123.123.123.0/24 10.99.81.0/24
http_access deny CONNECT
 # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
http_access allow services
# This one following maybe wrong (even in my config) ...
http_access allow all
visible_hostname cache-fe.domain.com
unique_hostname a2cpu1.cache-fe.domain.com
httpd_accel_host virtual
httpd_accel_port 0
httpd_accel_single_host off
header_access X-Cache deny all
httpd_accel_uses_host_header on

I use it in single_host=on mode, so I don't know what all the stuff
about "See also redirect_rewrites_host_header" is, you'll need to play
with getting squid to hit the right real server. In the above config
has got a good chance of working:

* Providing your application servers are still configured to answer to
their public IP address themselves.
* Providing your firewall intercepts all the public traffic to those IPs

and sends it to squid (after having NATed it first)
* Providing squid's connectivity to the public IP addresses of the
application servers is not distrupted by the firewall.
* Providing the squid hosts sends its default route back through the
firewall

[internet] <-> [firewall] <-> [squid] <-> [application servers]

should be dandy if you are using different network interfaces between
each...
if not then policy routing may help you out. Not sure if NT can do
that.

Another situation maybe that you have squid bind to any IP address on
TCP port 80 and you have multiple IP addresses (though IP aliasing) on
the same ethernet card. Each of these IPs will be the public IPs of the

respective websites you are fronting.

Then you are left in a situation that squid knows exactly which backend
host the intended request is for based on the IP your customer connected

to you one, but I really can't suggest how you go about setting up the
mapping.

Best of luck... :)

-- 
Darryl L. Miles