Re: [squid-users] Squid round-robin to 2 Apache's

On 4/02/2013 10:14 p.m., PARAM KRISH wrote:
> Hi Amox, Thanks so much for helping out... Here are my replies ..
>
> On Mon, Feb 4, 2013 at 1:39 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>> On 4/02/2013 8:22 p.m., PARAM KRISH wrote:
>>> Hello Squid Users
>>>
>>> I am in need of some help. I believe this must have been done by some
>>> already but i could not just get the right document to understand
>>> well.
>>>
>>> Setup :
>>>
>>> Squid v3.2.3 on a RHEL 6 64-bit VM (say server1)
>>> Apache's 2.2.15 on RHEL6 64-bit VM's (running in server1 and in server2).
>>>
>>> Requirement:
>>>
>>> 1. All http traffic should automatically redirect to https without a
>>> change in the url (except http -> https )
>>> 2. I have two URL's A.B.C.D and A.C.D both pointing to the server1 IP
>>> must work well.
>>> 3. When Apache in server1 dies, all traffic should work well with
>>> Apache in server2. All traffic must use Squid for
>>> ReverseProxy/Cacheing
>>>
>>> What i have done so far ?
>>>
>>> 1. Apache V-hosts (8080 & 443 ) : 8080 V-hosts does RewriteRule to https
>>> 2. Squid listens in 80 and 3123 (for ssl) having these entries in its
>>> config.
>>
>> Why 3123 (er actually 3128)? having different ports on the public-facing
>> proxy to what the backends are using is a common cause of trouble because
>> virtual-ports in HTTP are a tricky concept. Speaking of which...
>>
>> Also 3128 is a well-known proxy port. Using it for things other that normal
>> forward proxy traffic is another common cause of trouble. Usually from the
>> viral/worm side of the Internet.
> 3128 is what i am using. Sorry it was a typo of 3123. so, what port
> are you recommending to use if not this ? If i make it to listen to
> the same port of apache, everytime i restart Apache or squid , either
> of them complain that the port is already in-use.

This only happens if the IP address and port is identical. Which is why
I mentioned having the Apache on their own IP's.
One you have Squid operating they do not need to be accessible at all to
anyone but Squid.

>
>>> https_port 3128 accel cert=/usr/local/apache2/conf/folder/certnew.cer
>>> key=/usr/local/apache2/conf/folder/a.b.c.d.key defaultsite=a.b.c.d
>>> vhost
>>
>> This basic style SSL config does not support virtual hosting. You require
>> the certificate generator options to create certificates for each virtual
>> hosted FQDN on demand.
>> YHBW: This is not a very commonly used configuration (yet) and we have had
>> little feedback as to how well (or not) it works.
>>
>> NP: if you only have the one domain FQDN being hosted, OR multiple domains
>> all as aliases of one main domain, ... drop the vhost option.
> Our servers are for internal use and we use only self-signed
> certificates. Domains are local's and are in DNS rightly added.

You missed the point. The config you have is for servicing only the
domain "a.b.c.d" certificate key. No other domain will work properly
using that certificate. You *need* the dynamic certificate generation
feature of Squid when using "vhost" on https_port.

>>> http_port 80 accel defaultsite=a.b.c.d vhost
>>>
>>> cache_peer server1.b.c.d parent 8080 0 originserver round-robin
>>> cache_peer server2.b.c.d parent 8080 0 originserver round-robin
>>>
>>> What i understand is, requests coming to Port 80 (Squid) forwarded to
>>> either of Apache's 8080 where it gets rewritten to 443, processed.
>>
>> Erm, all requests arriving in both port 80 and port 3128 to your Squid are
>> sent to the Apaches port 8080 as plain-HTTP traffic. There is no distinction
>> between HTTP and HTTPS in a reverse-proxy. HTTPS is just a wire-level
>> TLS/SSL wrapping around regular HTTP after all. Once the reverse-proxy
>> https_port terminates the TLS/SSL it is gone.
>>
>> I think what you are actually seeing is that the Apache are handling the
>> traffic and have been configured to ensure all public URLs are
>> https://a.b.c.d:3128/, yes?
> No public URL's here. All internal links and available only for the
> internal employees.

'public' is a viewpoint relative to the service. I this case you have
two levels of 'internal' with the users / clients being
'public'-internal and the Apachies being 'private'-internal.

> My requirement is that all the http request to those two URL's
> (a.b.c.d and a.c.d) must get redirected(or rewritten) to https
> automatically.
> I was thinking having a Squid doing reverse proxy sniffing at 443
> would help to pick up from cache the next time we get the request,
> since this requirement is for mediawiki. Are you saying this wont do
> well or use-less ?

No. that is the wrong way to go about it.

You have the DNS for the domain pointing at Squid's IP. Have Squid
listening on both port 80 and 443 and receiving traffic.
Your Squid-3.2 can test for HTTP vs HTTPS and redirect clients to the
same URL under https:// like so...

  acl HTTP myportname 80
  http_access deny HTTP
  deny_info https://%H%R HTTP

The port-443 traffic gets past that and gets delivered to the Apaches.

>
> Also, when i tried like, squid listening on 443 through cache_peer of
> server1:443 and server2:443, i got something like this when apache1
> goes down.
>
> Bad Request
>
> Your browser sent a request that this server could not understand.
> Reason: You're speaking plain HTTP to an SSL-enabled server port.
> Instead use the HTTPS scheme to access this URL, please.
> Hint: https://server2.b.c.d/
>
> The hinted link when i click works fine but i obviously want this to
> be taken care automatically rather than popping to the user know that
> this is happening when server1 apache is dead.

Hmm. Okay that is the same problem as before, just with a different
error message.

Having thought about it a bit more I think you are hitting the bug where
round-robin, like all the specialized load balancing algorithms,
presents Squid with only one option of forwarding path at a time. So the
failover which Squid normally tries to do cannot work.
  Is there a particular reason you need round-robin? or would it work
just fine with two peers and letting Squid do failver when one gets
loaded/slow?

If you do require round-robin perhapse you would sponsor some work
(either in paid developer hours, or donating a patch) towards making
that algorithm work better with 3.2+?

Amos
Received on Mon Feb 04 2013 - 11:28:47 MST