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

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.

>> 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.

>> 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.
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 ?

> To both simplify and speed this all up:
> * use 443 as Squid listening https_port.
> * make the Apache listen on port 443 on their own IPs (can be internal
> private IPs).
> * configure the Apaches to "know" that a.b.c.d is their public FQDN.
> * remove any port re-writing config in the Apaches

I am not sure i understand that clearly.
If you are saying no re-writing in Apaches, and Apaches listening in
443 only, how(who) does http to https gets redirected if i implement
like this ?
Can you cover that part too please ?

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.

Thanks..
PK

>
>> This works well when both Apache's are running fine. When i bring down
>> Apache1, It breaks. Apache2 up/down does not make a difference as i
>> noticed though they are effectively used when both in running state as
>> i noticed from their logs. So it looks like they do effective
>> load-balancing in normal state, but cant take Apache1 from its
>> critical path.
>
>
> ? sounds like you have something else interferring. Possibly other
> cache_peer_* directives. Or Apache1 doing some re-writing to pass traffic to
> Apache2 somehow.
>
> Can you verify that Apache2 is actually receiving requests from Squid in
> equal proportions to Apache1 when both are available?
> And that none of their traffic is coming directly from clients to the
> Apache, or from each other directly.
>
>
>
>> Can you guys help me understand how i set this up ? I'm not sure the
>> http->https redirect must be done by Apache or the Squid or using any
>> redirector.pl within Squid. Which works best/faster ?
>
>
> The least changes/rewrites you make to the traffic flow the faster it goes.
> see above for a faster config.
>
>
>> Any help or reference doc / config would be much appreciated. I dont
>> have a requirement for people directly coming to server1 or server2 to
>> either of its 8080/443 ports. All traffic to be routed through the
>> domain url's "a.b.c.d" or "a.c.d" ONLY.
>>
>> Thanks a lot.
>
>
> Amos
Received on Mon Feb 04 2013 - 09:14:32 MST