Re: [squid-users] Accelerator mode, select peer form request destination ip (feature request?)

You seem to have mixed up your view of the information passed versus the
actions taken and what virtual hosting actually does.

On Mon, 2 Nov 2009 21:22:33 +0100, Justo Alonso <justo.alonso_at_gmail.com>
wrote:
> Hi !
> I'm trying to setup an apache & squid in accelerator mode
> configuration.

You start by indicating that you are trying to configure a reverse proxy.

>
> I have the apache in Listen *:80 .. with many virtualhosts and many
> namevirtualhosts (namevirtualhost *:80 too). I have the squid at
> http_port 8080.

Reverse-proxy do not work this way. I wonder if the many other meanings of
the word "accelerator" have confused you.

A reverse proxy is software talking to the client software pretending to
be a web server, but sourcing the replies over network from a real web
server elsewhere.

The client will type http://example.com/ into their browser address bar.
In your config that will take them directly to the apache.

To make a reverse-proxy useful you move apache to some other port and
place the proxy listening on port 80. Which then is configured to source
the data from apache on its other port.

So that when clients enter http://example.com/ into their browser address
bar it will take them directly to the proxy.

>
> And now I want squid to make the request to the apache to same
> destination ip that client requested .... example
>
> client request -> squid 10.0.0.1:8080 -> apache 10.0.0.1:80
> client rquest -> squid 10.0.0.2:8080 -> apache 10.0.0.2:80 ....

You then indicate that you want Squid to make actual physical TCP links to
different Apache. based on what the receiving Squid IP was. This has
nothing to do with virtual hosting.

This requirement is met by adding a cache_peer directive for each back-end
Apache server. Then using cache_peer_access and ACL of the "myip" type
limiting the requests passed to each peer to be those received on the
matching input IP.

>
> I want to configure one http_port and a cache_peer by virtualhost ...
> I need a global configuration ... all client requests redirected to
> the same destination ip to diferent port.

You then say that all these apache listening addresses are actually the
same machine.

cache_peer is designed to be a TCL link to a _single_ backend software.
Virtual hosting has nothing to do with it. This is so low down as to be
almost wire-level stuff.

Reading between the lines .... I guess that you actually want Squid to
pass the right information such that incoming requests are handled by the
right virtualhost inside Apache correct?

That is done correctly by having the right accelerator setup. Using
http_port settings vhost, vport and defaultsite to alter the Host: header
(virtualhost name) as applicable. The cache_peer forcedomain= option is
also available, but that is for force-sending only a single virtualhost
name to the Apache, opposite of what you want.

By setting squid to listen on port 80 the clients software will be sending
Squid the correct Host: header information as needed by apache to find the
virtualhost.

All you need to do is configure "http_port 80 accel vhost" and one single
cache_peer line pointing at Apache, and it works.
http://wiki.squid-cache.org/ConfigExamples/Reverse/VirtualHosting

>
> Reading the documentation I can't find about this, and I'm trying to
> add new option to cache_peer (same-dst-ip) .. if this boolean option
> is set then this cache_peer don't get the host and get the destination
> ip from request ... and open a connection to it on cache_peer port.
>
> What think you about this ?? comments ?? Maybe should I send this
> question to squid-dev list ?
>
> thanks in advance,
> justo

Your description of 'same-dst-ip' seems to me to be you attempting to make
squid a semi-transparent proxy instead of accelerator by opening security
vulnerability CVE-2009-0801 for reverse-proxy (accelerator) configurations
as well as interception-proxy configurations. This is a very bad idea.

If you find the basic accelerator config I outlined above still is not
workable for your specific needs then please get back to me on the details
of why you think this option might still be needed. I'm working on fixes
for the CVE and would like to make sure any such option fits with the
solution and does not open new vulnerabilities.

Amos
Received on Mon Nov 02 2009 - 22:26:05 MST