On Fri, 7 Oct 2005, Magne J. Andreassen wrote: > Hi, > > (This is a re-post from the -users list, thought it might be more > appropriate here) > > Exactly what kind of information does OpenVPN keep track of for active > VPN sessions? (after the authentication process is finished)
See struct context in openvpn.h -- this is the master object that denotes a VPN session. > Reason for asking; > > OpenVPN supports load-balancing trough the use of round-robin. Be it DNS > round-robin or just by specifying multiple servers in the client config > file. > > OpenVPN does not, however, support dynamic failover to another daemon > running on another server. By dynamic failover, I mean that the client > sessions are not interfered by the server going down or in other ways > being inaccessible. (They don't have to re-establish the tunnel) > > There was a thread on this list some time ago discussing clustering of > OpenVPN, but not so much details was given. > > > > OpenBSD has a dynamic failover / loadbalancing protocol called CARP that > some of you might be familiar with. It is ported to FreeBSD and Linux. > > PF (Packetfilter) and isakmpd uses some small synchronization daemons to > utilize the power of CARP and thereby offering dynamic failover for > these services. > > I think, without knowing much about the OpenVPN design, that it would be > possible to synchronize VPN client sessions in the same way and thereby > offering high-availability to OpenVPN clients. > > Why would I want this, you might ask? OpenVPN already supports > load-balancing trough the previous mentioned methods. Well, it's not so > much I don't trust these methods or my hardware. Rather, it's a major > strength when it comes to maintenance. I can have service windows in > office hours without users noticing the main VPN server goes down. This > saves time and money. And, clients currently connected to a failing > server, won't notice that they are "moved" to the backup server. > > Updating, patching and other maintenance could easily be done without > VPN service downtime. > > The strength in using CARP is obviously that OpenVPN don't have to > implement the redundancy protocol itself. > > So, the problems(?); > > The OpenVPN daemons mush listen on the same server ip-address. Actually, > it must utilize the CARP interface, so no changes to OpenVPN should be > necessary here. Using the '--local host' parameter and listening on the > CARP interface should be sufficient. > > OpenVPN should optionally use an external DHCP service to serve > addresses to the clients. If i remember correctly, someone on this list > mentioned that this could be done with a script? > > CARP and OpenVPN should be able to interact in some way, so that CARP > could adjust it's adskew (advertising interval deciding which server is > the master) if the OpenVPN daemon is unresponsive. > > As far as I can figure, the only thing that is required, is the OpenVPN > daemons to speak to each other and update client session information on > connect and disconnect. > > Depending on various parameters, the failover process takes about 1-5 > seconds. The clients might notice a stall in connectivity during this > time. Other than that, everything should be transparent to the user. > > > More problems; > > First I started to look at the possibility of writing a simple plugin to > take care of the synchronization and interaction with the various > OpenVPN daemons. But the problem is that the plugin API only offers > callbacks. In other words I don't think it's possible to "manually" add > a VPN session from a plugin. > > After skimming trough the various source files for OpenVPN, I think that > the problem might be a bit more complex than first assumed. > > Any comments on this? Any ideas on where the hooks should be placed in > OpenVPN to actually be able to sync sessions? The major issue to deal with when doing transparent, seamless failover is making sure that the new server inherits the precise state from the old server so that the switchover is invisible to the client. This is a complicated undertaking -- there's a lot of data that makes up a client instance object on the server. In a lot of respects, the problem of doing OpenVPN transparent failover is more akin to the problem of doing transparent failover for routers, than it is for doing failover for conventional "services" like SMTP or HTTP. So unless CARP supports router failover, it's probably not going to be a drop-in solution for OpenVPN. Longer term I would like to design a clustering feature for OpenVPN, that would also support seamless failover in under 5 seconds. However if you really want to do seamless failover now, without waiting for future development, you could probably do it this way: (1) Set up primary and backup OpenVPN servers. (2) Set up clients to always connect to both servers. (3) Set up VPN client <-> server routing through both primary and backup servers with the primary having a lower metric. (4) Have a server/up down sensor such as CARP dynamically change the routing metrics based on which server is available. This could be done by having CARP run a script every time there is a change in server/up down status -- the script would need to multicast a RIP2 or OSPF notification through the VPN to change the routing metric to prefer the currently alive server (I'm not sure if there's a command line tool to multicast dynamic routing updates). When we implement the clustering feature, the goal will be to automate the above steps. I will probably make plugin callbacks for (a) the server/up down sensor and (b) multicast of dynamic routing updates, so that these functions could be carried out outside of the OpenVPN core. James
