OpenVPN достаточно хорошо документирован и на хабре есть статьи по установке, к примеру:
вот эта.

Но так, чтобы сразу несколько тоннелей, между двумя серверами и автоматической отказоустойчивостью не нашел. В моем случае, серверы на которых будет располагаться OpenVPN и OSPF оба находятся за NATом. Это несколько усложняет решение, но в основном тем, что потребуется управлять трафиком, уходящим с интерфейсов пограничного маршрутизатора.

Дано:

Два пограничных маршрутизатора Centos 7:

r01:
ens0 1.1.1.1 – провайдер 1
ens1 2.2.2.2 – провайдер 2
ens2 10.0.0.1 – виртуальная сеть между шлюзом и OpenVPN сервером.
r02:
ens0 3.3.3.3 – провайдер 3
ens1 4.4.4.4 – провайдер 4
ens2 10.1.1.1 – виртуальная сеть между шлюзом и OpenVPN сервером.

Два OpenVPN/OSPF сервера Centos 7:

host01:
ens0 10.0.0.2 – SNAT через сеть провайдер 1.
ens0 10.0.0.3 – SNAT через сеть провайдер 2.
ens1 192.168.0.0/23 – локальная сеть.
host02:
ens0 10.1.1.2 – SNAT через сеть провайдер 3.
ens0 10.1.1.3 – SNAT через сеть провайдер 4.
ens1 192.168.4.0/23 – локальная сеть.

Все провайдеры в данной схеме разные, имеют разную скорость, стоимость.

Задача:

Создать 4 тоннеля между host01 и host02 так, чтобы они были всегда активны и в случае падения любого из провайдеров, маршрут должен переключаться на более медленный или дорогой канал. Даже если выйдут из строя оба провайдера (по одному на каждом сервере), канал также должен функционировать. В то же время, если более предпочтительный канал заработает – серверу придется перейти на него.

В этой статье я не буду подробно описывать процесс генерации ключей, установки OpenVPN, Quagga. Скажу лишь, что генерировать ключи для сервера и клиента достаточно один раз, так как можно использовать DH и все прочие ключи и сертификаты для всех инстансов одновременно. Но, конечно, если вы очень озабочены безопасностью – можно сгенерировать по два сертификата под каждый тоннель. В моем случае, был один сертификат на серверные службы и один на клиентские.

Установка:

Система CentOS Linux release 7.4.1708 (Core) / 3.10.0-693.5.2.el7.x86_64.
yum install openvpn easy-rsa quagga
версии ПО, которые были использованы:

openvpn 2.4.4 x86_64
easy-rsa 2.2.2-1.el7
quagga.x86_64 0.99.22.4-4.el7

Настройка:

Для тоннелей выбраны следующие порты:

udp 1150 – 1.1.1.1-3.3.3.3
udp 1151 – 2.2.2.2-4.4.4.4
udp 1152 – 1.1.1.1-4.4.4.4
udp 1153 – 2.2.2.2-3.3.3.3

Следует обратить внимание, что OpenVPN требует чтобы порт, с которого сервер и клиент отправляют пакеты был таким же как и порт приема пакетов, при использовании NAT порт исходящего пакета может отличаться и тоннель не поднимется с такой ошибкой:
TCP/UDP: Incoming packet rejected from [AF_INET]1.1.1.1:1194[2], expected peer address: [AF_INET]1.1.1.1:2364 (allow this incoming source address/port by removing --remote or adding --float)

Чтобы порт точно был всегда верным надо настроить пограничный маршрутизатор и OpenVPN сервер:

host01:

-A POSTROUTING -p udp --dport 1150 -o ens0 -j SNAT --to-source 10.0.0.2:1050
-A POSTROUTING -p udp --dport 1151 -o ens0 -j SNAT --to-source 10.0.0.3:1051

В свою очередь на пограничном маршрутизаторе будет так (r01):

-A POSTROUTING -p udp -s 10.0.0.2 --dport 1150 -o ens0 -j SNAT --to-source 1.1.1.1:1150
-A POSTROUTING -p udp -s 10.0.0.3 --dport 1151 -o ens1 -j SNAT --to-source 2.2.2.2:1151

Далее настроим туннели, приведу конфиг одной пары клиент/сервер, остальные настраиваются также, просто меняется порт, адреса и номер tun интерфейса.

Конфигурация сервера:

dev tun1
proto udp

topology subnet
remote 1.1.1.1
ifconfig 10.10.11.1 255.255.255.252

cipher AES-256-CBC
persist-tun
persist-key
ping 10
ping-restart 30

tls-server
daemon
dh /etc/openvpn/dh2048.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/srv.crt
key /etc/openvpn/srv.key

reneg-sec 300
port 1150
verb 3

Конфигурация клиента:

dev tun1
proto udp

topology subnet
remote 3.3.3.3
ifconfig 10.10.11.2 255.255.255.252

cipher AES-256-CBC
ping 10
ping-restart 30

tls-client
daemon

ca /etc/openvpn/ca.crt
cert /etc/openvpn/cli.crt
key /etc/openvpn/cli.key

reneg-sec 300
port 1150
verb 3

Важный параметр в конфигурации тоннеля topology subnet, он позволяет сделать адресацию тоннеля так, чтобы он выглядел как подсеть и не интерфейс точка-точка. Параметр не является параметром по умолчанию и рекомендуется для современных серверов. Без него нет возможности обмениваться широковещательными пакетами внутри тоннеля, тем самым не будет возможности настроить OSPF.

При поднятии тоннеля ifconfig на сервере и клиенте будет выглядеть так:

tun1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
inet 10.10.11.1  netmask 255.255.255.252  destination 10.10.11.1

tun1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
inet 10.10.11.2  netmask 255.255.255.252  destination 10.10.11.2

После того, как все 4 тоннеля подняты, получается такая картина.

udp 1150 – 1.1.1.1-3.3.3.3 – tun1 – 10.10.11.1-10.10.11.2
udp 1151 – 2.2.2.2-4.4.4.4 – tun2 – 10.10.12.1-10.10.12.2
udp 1152 – 1.1.1.1-4.4.4.4 – tun3 – 10.10.15.1-10.10.15.2
udp 1153 – 2.2.2.2-3.3.3.3 – tun4 – 10.10.16.1-10.10.16.2

Никаких дополнительных статических маршрутов добавлять не требуется, кроме добавления правил сетевого экрана:

-A FORWARD -o tun1 -m comment --comment "1" -j ACCEPT
-A FORWARD -i tun1 -m comment --comment "1"-j ACCEPT
-A FORWARD -o tun2 -m comment --comment "2" -j ACCEPT
-A FORWARD -i tun2 -m comment --comment "2"-j ACCEPT
-A FORWARD -o tun3 -m comment --comment "3" -j ACCEPT
-A FORWARD -i tun3 -m comment --comment "3"-j ACCEPT
-A FORWARD -o tun4 -m comment --comment "4" -j ACCEPT
-A FORWARD -i tun4 -m comment --comment "4"-j ACCEPT

Отказоустойчивость.

Можно добиться переключения маршрутов и с помощью скриптов, но получилось бы громоздкое и совсем не элегантное решение. Ранее мне не доводилось использовать динамическую маршрутизацию на практике. Протоколов довольно много, остановился я на OSPF, по большому счету, потому, что информации и способов применения нашел больше. Протокол linkstate типа, учитывает состояние каналов, интерфейсов и обменивается ею. Думаю, что вполне можно реализовать подобное на BGP или RIP. С радостью бы посмотрел на BGP версию решения.
Чтобы OSPF мог получать и отправлять служебные пакеты LSA – Link State Advertisement потребуется открыть порты на сетевом экране:

-A INPUT -i tun1 -p 89 -m comment --comment "multicast tun1"-j ACCEPT
-A INPUT -i tun2 -p 89 -m comment --comment "multicast tun2"-j ACCEPT
-A INPUT -i tun3 -p 89 -m comment --comment "multicast tun3"-j ACCEPT
-A INPUT -i tun4 -p 89 -m comment --comment "multicast tun4"-j ACCEPT

Перейдем к настройке Quagga.

Для начала надо убедиться что папки и файлы, фигурирующие в работе служб Quagga принадлежали пользователю под которым служба запускается:

chown  -R quagga:quagga /etc/quagga
chown  -R quagga:quagga /var/log/quagga/ospfd.log

Запускаем службы:

systemctl start zebra 
systemctl start ospfd

После этого можно начать конфигурировать OSPF.

В консоль можно попасть двумя способами, telnet или vtysh, я выбрал второе.
Лучше сразу же попробовать сделать write, чтобы проверить права на файлы конфигурации, иначе все команды, которые вы введете не сохранятся, должно получиться так:

host01# wr
Building Configuration...
Configuration saved to /etc/quagga/zebra.conf
Configuration saved to /etc/quagga/ospfd.conf
[OK]

Проверьте, все ли ваши интерфейсы доступны для zebra.

sh inter

Если маршрутизируемые через OSPF сети и все tun интерфейсы на месте, можно продолжать.
Прежде всего, необходимо настроить стоимость туннелей, чем меньше стоимость, тем приоритетнее туннель. Сделать это можно так:

interface tun1
 ip ospf cost 10

И далее для других tun2 30, tun3 15, tun4 20 в моем случае.

После чего можно запускать маршрутизатор:

router ospf
 ospf router-id 192.168.1.0
 redistribute connected route-map LAN
 passive-interface default
 no passive-interface ens0
 no passive-interface tun1
 no passive-interface tun2
 no passive-interface tun3
 no passive-interface tun4
 network 10.10.11.0/30 area 0.0.0.0
 network 10.10.12.0/30 area 0.0.0.0
 network 10.10.15.0/30 area 0.0.0.0
 network 10.10.16.0/30 area 0.0.0.0
 network 192.168.1.0/23 area 0.0.0.0
!
ip prefix-list LAN seq 10 permit 192.168.4.0/23
ip prefix-list LAN seq 100 deny any
!
route-map LAN permit 10
 match ip address prefix-list LAN

В данной конфигурации используется параметр redistribute connected для того, чтобы анонсировать не все маршруты на другой сервер, а только нужные, а параметр route-map LAN позволяет фильтровать сети.

Точно такая же конфигурация должна быть и с другой стороны тоннеля. После активации службы ospfd примерно через 10 секунд на обоих серверах появятся маршруты соседей и тоннель будет выбран согласно стоимости. В случае, если предпочитаемый тоннель перестанет работать, автоматически произойдет переключение на другой тоннель и так далее, пока тоннелей не останется. И также, если более удачный интерфейс снова будет активирован – маршрутизация пойдет по нему.

Примерное время обновления маршрутов 10 секунд, можно варьировать параметры ip ospf hello-interval и ip ospf dead-interval для сокращения этого времени.

Не забудьте добавить все службы в автозагрузку, к примеру мои файлы конфигурации OpenVPN называются srv-1050.conf и cli-1050.conf, в этом случае команды будут выглядеть так:

systemctl enable openvpn@srv-1050
systemctl enable openvpn@cli-1050

Спасибо за внимание, буду верить, что это кому-то пригодится.