A word to the wise.
I generally do NOT recommend external OpenVPN failover scripts. And this is NOT a criticism of anyone's efforts to do so, but just a realization that trying to detect and manage a failed VPN (however that is actually defined, which I'll get to in a moment) is a VERY difficult job. Even I would find it a challenge, and I've been working w/ OpenVPN and developing my own scripts for many, many years.
As anyone familiar w/ OpenVPN quickly realizes, it's not all that easy to detect a failure. It's not as if OpenVPN makes it obvious. It may attempt to retry the connection, sometimes indefinitely! The typical way YOU decide it's a failure in that case is if it takes too long to recover. And that's subjective.
I've found the best solution is to use a good, reliable VPN provider (and admittedly that's not always an easy task) and specify multiple remote directives (servers) in your config file. Here's an example of my own (w/ ExpressVPN, no secrets here).
Code:
server-poll-timeout 10
remote-random
remote us-new-york-2-ca-version-2.expressnetw.com 1195
remote usa-atlanta-ca-version-2.expressnetw.com 1195
remote usa-chicago-ca-version-2.expressnetw.com 1195
remote usa-dallas-2-ca-version-2.expressnetw.com 1195
remote usa-dallas-ca-version-2.expressnetw.com 1195
remote usa-denver-ca-version-2.expressnetw.com 1195
remote usa-losangeles-1-ca-version-2.expressnetw.com 1195
remote usa-losangeles-3-ca-version-2.expressnetw.com 1195
#remote usa-losangeles-ca-version-2.expressnetw.com 1195
remote usa-losangeles5-ca-version-2.expressnetw.com 1195
remote usa-miami-2-ca-version-2.expressnetw.com 1195
remote usa-miami-ca-version-2.expressnetw.com 1195
remote usa-newjersey-1-ca-version-2.expressnetw.com 1195
remote usa-newjersey-3-ca-version-2.expressnetw.com 1195
remote usa-newyork-ca-version-2.expressnetw.com 1195
remote usa-saltlakecity-ca-version-2.expressnetw.com 1195
remote usa-sanfrancisco-ca-version-2.expressnetw.com 1195
remote usa-seattle-ca-version-2.expressnetw.com 1195
remote usa-tampa-1-ca-version-2.expressnetw.com 1195
remote usa-washingtondc-ca-version-2.expressnetw.com 1195
The server-poll-timeout directive tells OpenVPN to only wait 10 seconds for a connection attempt before moving on to the next server. And in my case, I've decided to randomize that selection w/ the remote-random directive (the default is sequential).
The benefit here is that we let ***OpenVPN*** decide when and where to reestablish the connection, rather than try to manage it externally, via our own scripts. Nobody knows more about the state of affairs and how to proceed correctly than OpenVPN itself. I don't care how good any given external management script may be, it will never be able to handle all situations, or all situations as cleanly and effortlessly as you may be expecting. Not when it comes to that beast called OpenVPN.
In all my years of dealing w/ OpenVPN, I can't think of a single case where there was a need to failover to a *different* VPN provider, *provided* I was using a good, reliable VPN provider. But if you cheap out and expect some fly-by-night VPN provider who offered you a lifetime subscription for $10 to be that provider and work w/ these external management scripts, you're kidding yourself. Dollars to donuts that's likely the underlying cause of your problems. In short, no one should need failover scripts. OpenVPN is *designed* to handle failover itself, internally.
To make matters worse, using multiple VPN providers, you now have to duplicate all your PBR (policy based routing) (should you choose to go down that path) across the VPNs. Ugg.
The only circumstances I can imagine where you would actually need external failover protection is a) if the VPN provider was stupid enough to require completely different configurations (certs, keys, etc.) for different servers (ala, NordVPN years ago, and if that's the case, find a better provider), b) you insist on one very specific server location, and your VPN provider only offers one selection, so you employ several different providers (again, find a *single* better provider), or c) you fail to pay your bill, so your provider shuts you down, across the board (all servers).
OpenVPN isn't like your ISP, where you have the one and only option of a single connection, and if it fails, you're dead in the water without an external failover solution (e.g., dual WAN).
FWIW, my ExpressVPN setup as described above runs 24/7/365, flawlessly. On the rare occasion a connection drops/fails, it just moves on to the next server, transparently. Only way I know it even happened is if I happen to see it in the logs.
In short, at least for some of you guys, you're creating the very problem you're attempting to solve. The point of failure is NOT OpenVPN, it's YOU!
JMTC