OpenVPN OSPF между двумя серверами, множественные тоннели

OpenVPN OSPF между двумя серверами, множественные тоннели

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 версии ПО, которые были использованы:

Настройка:

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

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 сервер:

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

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

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

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

После того, как все 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📎📎📎📎📎📎📎📎📎📎