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

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.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.11
   Beta testers wanted for 3.2.0.4