Жили-были несколько серверов, в разных локациях. Сколько именно — это непринципиально, поэтому упростим, пусть будет два: A и B.
Каждый занимался своими задачами, а между собой они были соединены виртуальной приватной сетью (ну, то, что теперь нельзя называть).
Причем сеть эта использовалась по своему прямому назначению — просто обеспечить передачу локального трафика через публичные сети, дабы посторонние не совали в него свой любопытный клюв.
Однако, с некоторых пор начались проблемы: одна известная организация начала ломать рунет, блокируя соединения то там, то тут.
Сначала заблокировали один протокол — пришлось переходить на другой. Потом заблокировали другой — пришлось переходить на третий.
Третий периодически рвался, потому что начали портить уже соединения между сетями: через одного провайдера канал есть, через другого нет, потом меняются.
Как вы понимаете, нормальной работе это отнюдь не способствовало, пришлось искать какое‑то решение. А ведь оно давно известно — динамическая маршрутизация!
Просто до поры она, казалось бы, совсем тут не нужна — не те масштабы, да и работало всё прекрасно...
Смысл простой: если основной канал внезапно падает — используем резервный.
Портится резервный — меняем провайдера или ищем обходные маршруты.
Но для этого надо оперативно перенастраивать маршруты на роутерах, причем на всех сторонах всех участников процесса.
Каналы связи в данном случае — различные виды того‑что‑нельзя‑называть в различных сочетаниях.
Тут вполне подходит протокол OSPF: он как раз и предназначен для решения подобных задач.
Не буду пытаться обьяснять тонкости работы лучше, чем это делают профессионалы‑сетевики, просто остановлюсь на некоторых практических нюансах реализации.
А роутеры будут программные — для этого можно использовать пакет FRR.
Он стандартно присутствует в репозитарии Debian (apt search frr), но как показалось — лучше сделать немного по‑другому: запустить его через docker — тогда на всех узлах он будет одной версии, и не будет ни с чем конфликтовать.
Есть даже готовый образ — но, по обычаю, можно сделать и самостоятельно:
mkdir -p /etc/frr docker run -ti --name frr -v /etc/frr:/etc/frr --privileged --network host debian:latest
Это запускает контейнер с правами, близкими к хост-системе - но при этом сохраняется некоторая изоляция от системных библиотек и установленных версий ОС.
Попадаем внутрь контейнера - устанавливаем:
apt update apt upgrade apt install frr exit
Теперь в контейнере живет frr, а его настроечные файлы - в /etc/frr host-системы.
То есть, их можно редактировать вручную в привычном редакторе.
vim /etc/frr/daemons ospfd=yes
Теперь немного сетевых настроек.
Разрешаем форвардинг, если еще не:
sysctl net.ipv4.ip_forward=1
Назначаем фиксированные, независимые от интерфейсов адреса для серверов, присваивая их локальному интерфейсу, ну например, адрес сервера A - 192.168.10.1
Таким образом, их наличие никак не будет связано с работоспособностью тех или иных сетевых интерфейсов:
ip addr add 192.168.10.1/32 dev lo
Разбираемся с каналами: это у нас различные типы того-что-нельзя-называть, причем нам от них по сути нужна связь "точка-точка": соединяются сервера A, B, а также несколько дополнительных, размещенных в других локациях - для организации подобия mesh-сети.
По сути для каждого из них нужны всего 2 адреса + широковещательный и адрес подсети, итого 4.
Для этого можно выделить специальную отдельную подсеть, например, 192.168.5.0, и нарезать ее на подсети /30.
Кто забыл: маска подсети - количество неизменяемых битов подсети, т.е. /24 - первые три октета фиксированы(192.168.5.), и еще 6 бит - тоже.
В двоичном виде последний октет будет выглядеть так:
(0000 00)00 - в скобках фиксированная часть подсети, без скобок - 00, 01, 10, 11 - адреса сети, узлов и широковещательный соответственно.
А номера сетей меняются от 0000 00 до 1111 11.
Поскольку всё это принято записывать в десятичном виде - можно для удобства использовать встроенную в шелл возможность расчёта:
echo $(( 2#00000001 )) # 1 - 1 адрес сети 0 echo $(( 2#00000010 )) # 2 - 2 адрес сети 0 echo $(( 2#00000101 )) # 5 - 1 адрес сети 1 echo $(( 2#00000110 )) # 6 - 2 адрес сети 1 echo $(( 2#00001001 )) # 9 - 1 адрес сети 2 echo $(( 2#00001010 )) # 10 - 2 адрес сети 2
Ну и так далее. Несложно.
К примеру, связываем сервера A и B двумя прямыми каналами:
192.168.5.1/30 - 192.168.5.2/30 # то-что-нельзя-называть тип 1 192.168.5.5/30 - 192.168.5.6/30 # то-что-нельзя-называть тип 2
Ну и так далее. Еще раз отмечу, что это чисто "связные подсети", на них не будет работающих сервисов.
Сервисы у нас на 192.168.10.1 и подобных.
Теперь запускаем frr:
docker start frr docker exec -ti frr /usr/lib/frr/frrinit.sh start
У frr есть Cisco-подобный интерфейс, через который можно делать настройки и смотреть состояние:
(TAB помогает)
docker exec -ti frr vtysh configure terminal router ospf ospf router-id 1.1.1.1 maximum-paths 1 network 192.168.10.1/32 area 0 network 192.168.5.0/24 area 0 exit exit write memory exit
И смотрим, что получилось:
vim /etc/frr/frr.conf frr version 10.3 frr defaults traditional hostname alice log syslog informational service integrated-vtysh-config ! router ospf ospf router-id 1.1.1.1 maximum-paths 1 network 192.168.10.1/32 area 0 network 192.168.5.0/24 area 0 exit !
Синтаксис простой, блоки выделяются отступом, символ ! или # - комментарий, в данном случае они вообще не обязательны и служат просто для визуальной отметки конца блока.
(тут, к слову, та самая ситуация, когда один лишний пробел может поломать всё)
Если что-то поменять - потом достаточно перезапустить frr:
docker exec -ti frr /usr/lib/frr/frrinit.sh restart
Ну или воспользоваться vtysh для правки, кому что привычнее.
Что сейчас настроено:
роутер OSPF с ID 1.1.1.1 (похоже на IP, но на самом деле просто номер, номера должны быть разными)
анонсируется маршрут к сети 192.168.10.1/32, состоящей из единственного адреса.
анонсируются маршруты всех сетей, попадающих в маску 192.168.5.0/24, то есть всех «связных».
ограничено количество одновременно работающих путей — чтобы не нарушалась работа TCP‑соединений.
По интерфейсам, подпадающим под маску, будут рассылаться сообщения Hello от OSPF - предполагается, что с другой стороны их будут слушать другие OSPF-роутеры.
По такой же схеме настраиваем FRR на других машинах.
Если там нет своих "сервисных адресов" - достаточно указать только одну сеть, через которую идёт связь, в данном случае 192.168.5.0/24
И в общем-то это всё.
Перезапускаются frr, они обмениваются между собой данными о доступных маршрутах - и теперь на любой машине можно обратиться к 192.168.10.1 - запрос уйдет именно на сервер A, по кратчайшему маршруту, в зависимости от того какие каналы где сейчас работают.
Проверить работу можно так:
docker exec -ti frr vtysh show running-config show ip ospf neighbor show ip ospf route ...
А вот теперь нюансы:
Протокол OSPF - это не TCP и не UDP, это отдельный протокол 89.
Поэтому некоторые, эээ, каналы, его не пропускают.
Решить эту проблему можно примерно следующим образом: сначала поднять просто TCP/IP канал, потом поверх него VXLAN (L2, "езернет", инкапсулированный в UDP), потом поверх него "связную сеть", и вот уже тогда пускать OSPF.
Слоёный пирог, но работает. Альтернатива - использовать BGP, но там настройка несколько сложнее.
Address = 192.168.3.1/30 Table = off PostUp = ip link add vxlwgA type vxlan id 12 dev %i remote 192.168.3.2 dstport 4789 PostUp = ip link set dev vxlwgA up PostUp = ip addr add 192.168.5.9/30 dev vxlwgA
Вданном случае сначала устанавливается «транспортная подсеть» 192.168.3.0/30, поверх нее «связная подсеть» 192.168.5.4/30, и вот уже по ней и будет работать OSPF.
А 192.168.3.0 в маршруты не попадёт (хотя можно и ее добавить, еще одной network).
Заметим, что статические маршруты тут не нужны, и даже вредны — оно само всё разрулит лучше.
Теперь включаем ping, и начинаем портить:
отключаем один прямой канал — маршрут перестаивается через другой.
отключаем второй — маршрут перестраивается в обход, через другой интерфейс.
отключаем и там — маршрут пошел через третий сервер
Для приложений, работающих с 192.168.10.1, будут лишь кратковременные потери пакетов, может вырасти время пинга, особенно если меняется вообще способ подключения — но в целом всё работает, хоть и идет неведомыми путями.
А значит, цель достигнута.