Re: [squid-users] problem using squid as proxy server to load balance reverse-proxies

On Fri, Feb 11, 2011 at 1:14 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 12/02/11 06:37, Sri Rao wrote:
>>
>> Hi Amos,
>>
>>
>>>>>>
>>>>>> I am trying to setup squid as a ssl proxy to load balance btwn
>>>>>> reverse-proxies.  I believe the config is right but what is happening
>>>>>
>>>>> What you have setup is a forward proxy load balancer which only permits
>>>>> management and binary-over-HTTP tunneled traffic from its localhost
>>>>> machine
>>>>> IP.
>>>>
>>>> That is actually what I want.  I want to do binary-over-HTTP from the
>>>> localhost to the reverse-proxy servers.  When the forward proxy tries
>>>> to connect to the origin server directly it does a tunnelConnect but
>>>> even though I have set originserver for the cache_peers it seems to
>>>> just forward the CONNECT instead of doing a tunnelConnect.  I thought
>>>> originserver should force squid to treat the cache_peers as if they
>>>> were web servers?
>>>
>>>
>>> It should. You seem to have found a bug there. I've added a fix for that
>>> now.
>>
>> Where can I grab the fix?
>
> It will be here when the mirrors next update:
> http://www.squid-cache.org/Versions/v3/3.1/changesets/squid-3.1-10230.patch

>
>>
>>> A secondary problem in your config was "never_direct allow sp_test" -
>>> since
>>> sp_test always matches direct tunnel setup (tunnelConnect) is not
>>> permitted.
>>
>> yeah I never want it to go direct to the origin.  I want it to connect
>> to the peers but as the originserver which should still be
>> tunnelConnect right?
>
> Hmm, I think I finally get what you are trying to do. :)
> And no Squid's handling of CONNECT is not smart enough to do CONNECT
> properly to origins when the origin is a cache_peer without direct TCP
> access from Squid.
>
>
>  tunnelConnect is Squid being a gateway and converting the CONNECT into a
> TCP tunnel directly CONNECTed from to the destination server. Similar to the
> way SSH would for example. Bytes are shuffled but squid sees none of them.
> Like so:
>   client--(CONNECT)-->Squid --(direct TCP)-->some host
>
>  using cache_peer is Squid passing an HTTP requests (just happens to be
> CONNECT) on unchanged for another proxy cache_peer to process. The tunnel
> data is just a regular HTTP body entity to Squid, same as a POST with data
> going both ways to the client and cache_peer.
> Like so:
>   client--(CONNECT)-->Squid--(CONNECT)-->Other proxy--(direct TCP)-->some
> host
>
> inside the tunnel:
>        client <--(binary)--> some host
>
>
> In your case you have the peer origins hostname in the CONNECT destination
> yes? so allowing CONNECT to go direct will go there.
>  I think you should be doing "never_direct deny" of everything *except*
> CONNECT requests to your internal origins.

Okay let's say I am trying to loadbalance using squid to 2 origin
servers. The 2 origin servers would be setup as cache_peers applying
the originserver directive no? Right now that wouldn't happen. It
would return not allowed for cache_peers right? The patch below would
allow for cache_peers if set as originserver to do the passthru you
are talking about above.

I thought a possible patch could be:

diff -Naur squid-3.1.11/src/tunnel.cc squid-3.1.11-cf/src/tunnel.cc
--- squid-3.1.11/src/tunnel.cc 2011-02-07 20:05:51.000000000 -0800
+++ squid-3.1.11-cf/src/tunnel.cc 2011-02-11 11:08:34.256181949 -0800
@@ -589,10 +589,10 @@
         err->callback_data = tunnelState;
         errorSend(tunnelState->client.fd(), err);
     } else {
- if (tunnelState->servers->_peer)
- tunnelProxyConnected(tunnelState->server.fd(), tunnelState);
- else {
+ if (!tunnelState->servers->_peer ||
tunnelState->servers->_peer->options.originserver)
             tunnelConnected(tunnelState->server.fd(), tunnelState);
+ else {
+ tunnelProxyConnected(tunnelState->server.fd(), tunnelState);
         }

         commSetTimeout(tunnelState->server.fd(),

Wondering if there are reasons that this shouldn't be done?

Sri
Received on Sat Feb 12 2011 - 09:05:16 MST