multifactor authentication for distributed VPN mesh - part 3, VPN mesh

Printer-friendly version

One VPN server not reliable enough? Create more than one, and connect them together.

This is part 3 of a series of articles:

This is just a sketch, describing the major steps. Everything said in the previous articles in this series still applies. Basically, you need to create more than one OpenVPN server, and link them all together.

The goal is to have several VPN servers that are functionally identical. No matter what server a client will connect to, it will work exactly the same.

On each VPN server, in /etc/openvpn, create a new, separate openvpn process, with its own .conf file and its own certificate. One of these new openvpn processes must be configured as a server; all the others must be configured as clients. These are collectively known as replication VPN servers and clients, or replication VPN sub-mesh.

Configure all replication VPN clients to connect to the replication VPN server. This is all just basic OpenVPN configuration, see previous articles in this series and the OpenVPN HOWTO. Make sure that the replication VPN processes are passing traffic in all directions.

Configure all MySQL databases for replication. It has to be master/master replication; master/slave will not work. To make them all talk together, use the IP addresses in the replication VPN sub-mesh. Make sure replication works. You need to replicate the Radius DBs, and the Yubico DBs (if applicable).

You will have to setup a lot of routes between VPN servers, routing through the replication VPN sub-mesh. You could do this via static routes - this works with a simple setup, but quickly becomes hard to maintain.

Or you could use dynamic routing. On each VPN server, run a dynamic routing daemon. Open source routers such as Quagga, XORP, BIRD, etc. work well. Probably an OSPF mesh would work well for this type of scenario. In any case, the dynamic routing configuration is pretty minimal - this is not a complex OSPF setup. All you need is each VPN server to learn routes pushed by all the other servers, that's all.

Create a single DNS hostname, such as vpn.domain.com, and alias it to all individual VPN servers: vpn01, vpn02, etc. Make all clients connect to vpn.domain.com. Use a low TTL for this record. This way, if a VPN server is down, a client may try it briefly, but then it will switch to another server.

Tags: