|
It may be my failing, but perhaps I didn't explain well enough. I'll
attempt to do so here, with a cute ascii diagram, as best my ability:
User
|
Firewall ----> VIP (load balancer,
10.0.0.24=https://www.https1.com, 10.0.0.34=https://www.https2.com)
^ ^
^ ^
192.168.1.23(srv1) 192.1681.25(srv2) 192.168.1.24(srv1)
192.168.1.26(srv2)
I have 2 servers, each behind the load balancer. Each server has 2 ssl
sites, 2 different ssl certificates. www.https1.com, www.https2.com,
both reside on each server.
The vhost is configured so that each ssl is bound to it's own ip, as
name based hosting doesn't work for ssl sites in apache (I'm aware of this).
Each realserver has the dummy eth module installed, and multiple ip's,
in a fashion of dummy0=10.0.0.24, dummy0:1=10.0.0.34.
If I bind the ssl in apache vhosts to an ip, like this <virtualhost
192.168.1.23:443>, then for whatever reason, apache refuses to work with
the load balancer, perhaps because it doesn't know to answer requests
using the vip, however, if I seperate them, and have one server with
<virtualhost *:443>
vhost1 settings
</virtualhost>
and the other server with
<virtualhost *:443>
vhost2 settings
</virtualhost>
Things work fine, but there's no load balancing, and no redundancy.
Any ideas at all?
Michael
Graeme Fowler wrote:
> On Tue, 2007-10-16 at 17:48 -0700, Michael Moody wrote:
>
>> I have LVS-DR on gentoo 2006.1, kernel 2.6.20.
>>
>
> OK...
>
>
>> I am running multiple ssl vhosts (ip-based) on each realserver.
>>
>
> OK... remember however that although you bind a given SSL virtual host
> to a single IP address, the certificate is in the *name* of the site,
> not the IP.
>
>
>> However, if I go to the vip, via https://10.0.0.20, I get an ssl error.
>>
>
> This is to be expected. It is a well-known catch-22 using SSL for web
> hosting - the TLS/SSL session is established over the IP connection
> *before* the HTTP application layer comes into play.
>
> During the TLS negotiation, the server sends back the public part of the
> certificate; this contains a "Subject" attribute something like this:
>
> Subject: C=GB, ST=Leicestershire, L=Loughborough, O=Graeme Fowler,
> OU=linuxvirtualserver.org, CN=www.linuxvirtualserver.org
>
> The CN attribute in that line is what the browser then compares against
> the virtual host being requested - if they don't match, it throws an
> error.
>
> Only when the TLS session is established can the client say:
>
> GET / HTTP/1.1
> Host: 10.0.0.20
>
> (which is what the browser says when using the URI you gave as an
> example).
>
>
>> What it appears like to me is that since apache is listening on
>> 192.168.1.24, it can't respond to requests from the load balancer since
>> it's not also listening on the vip. Is there a way to make it listen on
>> the vip as well? What am I doing wrong?
>>
>
> Don't connect to the VIP by IP address using SSL. If you must, your
> browser will not be able to validate the certificate and will throw an
> error.
>
> As an interesting exercise, try connecting to the realserver's IP
> address from a machine local to it; you'll get the same problem.
>
> Aside from the validation problem, is anything else the matter?
>
> Graeme
>
>
>
>
--
Michael S. Moody
Systems Engineer
Global Systems Consulting
Direct: (650) 265-4154
Web: http://www.GlobalSystemsConsulting.com
Engineering Support: support@xxxxxx
Billing Support: billing@xxxxxx
Customer Support Portal: http://my.gsc.cc
NOTICE - This message contains privileged and confidential information intended
only for the use of the addressee named above. If you are not the intended
recipient of this message, you are hereby notified that you must not
disseminate, copy or take any action in reliance on it. If you have received
this message in error, please immediately notify Global Systems Consulting, its
subsidiaries or associates. Any views expressed in this message are those of
the individual sender, except where the sender specifically states them to be
the view of Global Systems Consulting, its subsidiaries and associates.
|
