I've done this a couple of times, and the first was a real noggin scratcher - so I know what you are going through. Sounds like you've got it figured out.
You setup the ssl_cert as though it is going to be one server (using the external ip of the LVS. Install the cert on both internally NAT-ed boxes using the same cert (just as if each box were really the external server). It works a charm. The cool thing about this setup is one cert services any number of back-end servers. Once the LVS is in place and running, you can easily add more servers or take servers out of play with just a few strokes of the keyboard. BTW: disk imaging works really well on the interior servers. Also I recommend setting up rsync to monitor the web content and keep it synchronized across servers - though a lot of web-authoring applications will do this for you automagically. I also recommend that you have a second firewall setup as a fail-over to the primary. You can also use this firewall in a circular routing procedure so that machines inside the LVS can access the external IP normally. "Huh?" you say... "what was that last thing?" Here's what will happen: - you hop onto one or both of the internal servers and modify a web page, - you want to check on the change so you browse the web-site (from the server you are currently on) - you wait for the page to resolve - you wait - you wait Huh... you can't browse to any of the web-pages on the LVS! Is it down? But wait, none of your buzzes or whistles are going off - you're network monitoring is still seeing the web site as up and running. You browse to it from your workstation and ... Viola! It's all there - including your changes. You go back to the server (one of the inside LVS servers) and try the browse again... it doesn't work. It doesn't work because the internal LVS servers *must* use the external LVS server as their gateway. This gateway is already "reverse NAT-ing" the external IP address (sending requests into the private IP addresses of the internal LVS servers), and you are sending a request from one of the private ip's out that same gateway. When the request turns around and tries to come back in, the server sees what looks like a circular NAT and won't process the second incoming "reverse NAT". So any internal server using the external LVS server as a NAT-ing gateway is not allowed to browse the LVS-ed Web server. You get around that by playing with the routing tables on the internal servers and pointing to a different firewall to access the external LVS IP address. Now that is as clear as mud. Anyway, I hope it's helpful. Jon Carnes === On Tue, 2003-06-10 at 10:38, John Turner wrote: > I am setting up a LVS server to front 2 boxes running Apache and I want > to setup https. > > So when I order my ssl_cert I would use the FQDN of the virtual > interface? > Do I need to get a different ssl_cert for each real-server? > > Anything else I need to be aware of during this process? > > Thanks, > John > > _______________________________________________ > TriLUG mailing list > http://www.trilug.org/mailman/listinfo/trilug > TriLUG Organizational FAQ: > http://www.trilug.org/faq/TriLUG-faq.html _______________________________________________ TriLUG mailing list http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ: http://www.trilug.org/faq/TriLUG-faq.html
