On Tue, Nov 3, 2009 at 12:12 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> Justo Alonso wrote:
>>
>> Hi Amos !
>>
>> On Mon, Nov 2, 2009 at 11:26 PM, Amos Jeffries <squid3_at_treenet.co.nz>
>> wrote:
>>>
>>> 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.
>>
>> It's ok .. the port it's not important. In my configuration, the
>> firewall nat the 80 port to 8080 in the sites with reverse proxy:
>>
>> client to www.example.com:80 -> fw nat www.internal.example.com:8080
>> -> squid cache in 8080 -> apache in 80
>
> Alert!! your Squid is now a NAT interception proxy.
>
> IP addresses as viewed by Squid are always:
> src: client.IP with random port
> dst: www.internal.example.com with port 8080
???
>
>>
>> So, the client get http://www.example.com in your browser and the
>> squid receive the request in 8080 port .. The port it's not important.
>>
>>>> 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.
>>
>> Yes, if you have namevirtualhosting. If you have many virtualhost and
>> many namevirtualhost (the machine with apache and squid has many
>> interface aliases)
>>
>> With namevirtualhost and virtualhost apache selects the correct
>> configuration for the site with the destination ip and port and the
>> servername/serveralias directives
>
> Due to NAT above destination IP is erased and replaced with a constant
> value.
>
>>
>>> 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.
>>
>> Yes, but this makes the configuration very complex. You need to
>> configure one cache_peer by interface and acls for cache_peer .. if
>> you have about 150 interfaces per machine .. the posibility to make a
>> mistake it's higher !
>>
>>>> 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.
>>
>> ummm ... but .. if the same-dst-ip option is defined on this
>> cache_peer, we can change the cache_peer configuration or create a
>> dynamic cache_peer for attend this request setting the host of this
>> cache_peer to the destination ip (the ip that the squid receive the
>> request)
>>
>>>
>>> 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
>>>
>>
>> But my apache listen on diferent interfaces and have namevirtualhost
>> configuration, then one cache_peer don't work fine.
>>
>>>> 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.
>>
>> The CVE-2009-0801 doesn't apply with this configuration ... It's the
>
> Client can connect to any of Squid IPs and forge Host: info of any apache
> IP. In your case it just has very limited impact.
> With dst-ip option that will make squid ignore cache_peer explicit
> destination and loop back on itself.
>
>> same case as if the client connects directly to the web server. Squid
>> doesn't selects the cache_peer by Host header .. selects by
>> destination ip of the request.
>
> Above you said NAT was involved.
> "client to www.example.com:80 -> fw nat www.internal.example.com:8080"
>
> Therefore destination IP will _always_ be IP www.internal.example.com
> because NAT erased the real destination IP and replaced it.
>
> This breaks your option as described for accelerators.
>
>>> 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
>>>
>>>
>>
>> justo
>
> Given that your Squid is really a NAT interception proxy you can drop the
> pretense of configuring it as an accelerator...
no, I don't want a transparent proxy (nat interception) I want an
accelerator for the web servers (indepently of my infrastructure,
firewall and balancers, needs)
>
>
> http_port 8080 transparent
>
> acl toapaches dst 10.0.0.0/8
> http_access allow toapaches
>
> Will do exactly what you are asking to be done. Squid will decode the Host:
> header, look it up in DNS and send the request to the relevant server IP and
> port as encoded by the client.
>
> Now all you need do is make the DNS resolver tell Squid what internal apache
> IP for all the namevirtualhosts that apache services (DNS views). You can
> even have multiple IPs returned for each name to make seamless failover
> between apaches when some go down.
>
This solution works, but then I need to configure the /etc/hosts (or
bind views) for the web servers farm .. more complex configuration ->
mixtake sure !
Finaly, what I need is a cache_peer selector by destination ip not by
Host header or dns lookup.
thanks in advance,
justo
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
> Current Beta Squid 3.1.0.14
>
Received on Tue Nov 03 2009 - 12:09:08 MST
This archive was generated by hypermail 2.2.0 : Tue Nov 03 2009 - 12:00:02 MST