On Fri, Feb 11, 2011 at 1:14 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> 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
