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
