Search squid archive

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux