BGP и BFD
в небольшом контуре. BGP and BFD
in a small production network.

Нужно было связать несколько серверов на разных площадках и дать им постоянные внутренние адреса. При отказе одного туннеля связь должна сохраняться без изменения DNS и ручной замены маршрута.

Ниже показана обезличенная версия решения, которое я внедрил и описал в эксплуатационном ранбуке. Адреса, имена узлов и параметры конкретного контура заменены документационными примерами; устройство сети и порядок переключения сохранены.

Адрес узла отдельно от транспорта

Ключевое решение — не считать адрес WireGuard адресом сервера. Каждый узел получил собственный постоянный /32 на локальном интерфейсе mesh0. Именно этот адрес публикуется во внутреннем DNS и используется приложениями.

У WireGuard и IPsec отдельные транзитные сети. WireGuard работает с Table = off, StrongSwan не устанавливает прикладные маршруты самостоятельно. Маршрут выбирает только FRR: к одному удалённому /32 он видит два BGP-маршрута.

• 01Адрес узлапостоянный /32 на mesh0
• 02Основной путьполносвязный WireGuard
• 03Резервный путьIKEv2/IPsec через XFRM
• 04Выбор путиFRR, BGP и BFD

Почему здесь BGP, а не два статических маршрута

Статические маршруты просты, пока отказ можно определить состоянием интерфейса. Для туннеля этого недостаточно: интерфейс способен оставаться поднятым, когда удалённый конец или промежуточный путь уже недоступен. BGP даёт явное состояние соседства и политику, а BFD связывает выбор маршрута с доступностью конкретного транспорта.

Соседство строится дважды для каждой пары: через WireGuard и через XFRM. Маршрут, полученный по WireGuard, получает local-preference 200; резервный IPsec остаётся со значением 100. Входные списки разрешают от соседа только его служебный /32, исходный список — только собственный. Ошибка в конфигурации одного узла не должна превратить небольшой контур в транзитную сеть.

ip prefix-list PEER-A-IN seq 10 permit 192.0.2.20/32
ip prefix-list SELF-OUT seq 10 permit 192.0.2.10/32

route-map WG-PREFER permit 10
 set local-preference 200

router bgp 64512
 bgp router-id 192.0.2.10
 neighbor 198.51.100.2 remote-as 64513
 neighbor 198.51.100.2 bfd
 neighbor 203.0.113.2 remote-as 64513
 neighbor 203.0.113.2 bfd
 address-family ipv4 unicast
  network 192.0.2.10/32
  neighbor 198.51.100.2 route-map WG-PREFER in
  neighbor 198.51.100.2 prefix-list PEER-A-IN in
  neighbor 203.0.113.2 prefix-list PEER-A-IN in
  neighbor 198.51.100.2 prefix-list SELF-OUT out
  neighbor 203.0.113.2 prefix-list SELF-OUT out

BFD без гонки за миллисекундами

В этом контуре не требовалась скорость переключения магистрального маршрутизатора. BFD отправляет проверку раз в минуту, а три пропущенных ответа подряд снимают соседство. После обрыва маршрут меняется за две-три минуты: короткой потери пакетов или занятой виртуальной машины для этого недостаточно.

Две-три минуты здесь — осознанный запас от кратких потерь пакетов, а не попытка получить самое быстрое переключение.

В штатном состоянии оба транспорта подняты заранее. Переключение не ждёт нового согласования IKE: BGP удаляет основной маршрут и сразу использует уже существующий путь через XFRM. После восстановления соседства более высокий local-preference возвращает трафик в WireGuard.

Как проверялось реальное переключение

Остановка всего WireGuard-интерфейса — плохой тест: она одновременно задевает все связи узла. В ранбуке тест ограничен одной парой. Временные правила блокируют BFD и BGP только от выбранного соседа, после чего скрипт ждёт маршрут через XFRM, проверяет ICMP и прикладной запрос, снимает блокировку и подтверждает возврат основного пути.

Этот тест я добавил в регламент обслуживания и периодически повторяю для выбранной пары. Сначала фиксирую исходный маршрут, затем работу через резерв и возврат в WireGuard; в конце сверяю соседства, туннели и прикладной запрос.

#!/bin/bash
set -euo pipefail

peer=198.51.100.2
target=192.0.2.20
bfd=(-i wg-mesh -s "$peer" -p udp --dport 3784 -j DROP)
bgp=(-i wg-mesh -s "$peer" -p tcp --dport 179 -j DROP)
blocked=0

cleanup() {
  if test "$blocked" -eq 1; then
    iptables -D INPUT "${bfd[@]}" 2>/dev/null || true
    iptables -D INPUT "${bgp[@]}" 2>/dev/null || true
  fi
}
trap cleanup EXIT INT TERM

iptables -I INPUT 1 "${bfd[@]}"
iptables -I INPUT 1 "${bgp[@]}"
blocked=1

fallback=0
for attempt in $(seq 1 12); do
  route=$(ip route get "$target" | head -n 1)
  case "$route" in
    *" dev xfrm"*) fallback=1; break ;;
  esac
  sleep 15
done
test "$fallback" -eq 1

ping -c 3 -W 2 "$target"
curl --resolve "service.example:443:$target" \
  --fail --max-time 10 https://service.example/health

cleanup
blocked=0

recovered=0
for attempt in $(seq 1 12); do
  route=$(ip route get "$target" | head -n 1)
  case "$route" in
    *" dev wg-mesh "*) recovered=1; break ;;
  esac
  sleep 15
done
test "$recovered" -eq 1

trap здесь — только страховка. Ранбук отдельно требует убедиться, что временных правил не осталось, маршрут снова проходит через WireGuard, оба BGP-соседства установлены, BFD поднят, а прикладной запрос проходит в обоих направлениях.

Наблюдаемость без лавины одинаковых событий

Zabbix получает состояние выбранного транспорта, свежесть рукопожатий WireGuard и наличие IPsec SA. Для каждого удалённого узла формируется один снимок: основной путь, резерв и фактически выбранный маршрут. Зависимые показатели строятся из этого снимка без повторного запуска системных команд.

route=$(ip -4 route get "$target" 2>/dev/null | head -n 1 || true)

case "$route" in
  *" dev wg-mesh "*) transport=1 ;; # основной
  *" dev xfrm"*)    transport=2 ;; # резервный
  *)                transport=0 ;; # маршрута нет
esac

printf '{"peer":"%s","transport":%s,"wg":%s,"ipsec":%s}\n' \
  "$peer" "$transport" "$wg_available" "$ipsec_available"

Состояния собираются на всех узлах, но события о сетевой связности создаёт один наблюдатель. Иначе отказ одной машины породил бы зеркальные уведомления со всех остальных. Общая авария также сворачивается в одно событие, а не в набор одинаковых проблем по каждому соседу.

Новый узел меняет всю матрицу связей

В небольшом контуре полносвязная схема остаётся управляемой, но каждый новый сервер образует по одной паре WireGuard и IPsec с каждым действующим узлом. Перед генерацией конфигурации ему выделяются постоянный адрес /32, транзитный адрес WireGuard, номер автономной системы, публичный и локальный адреса для IKE; затем адреса проверяются на пересечения на всех серверах.

Оба закрытых ключа создаются на новом узле. Наружу выходят только открытый ключ WireGuard и публичная часть ключа IPsec. После выпуска узлового сертификата новый сервер сначала подключается ко всем действующим, затем обновлённые открытые конфигурации раскладываются по остальным узлам последовательно. Между шагами сеть проверяется, поэтому ошибка затрагивает один узел, а не вызывает одновременный перезапуск всего контура.

1. Инвентарь. Зафиксировать идентификатор, имя, постоянный и транзитный адреса, ASN, NAT и конечные точки.
2. Ключи. Создать закрытые ключи локально; в рабочий каталог передать только открытые части.
3. Генерация. Получить XFRM-интерфейсы, StrongSwan и FRR для каждого узла и проверить изменения.
4. Развёртывание. Сначала новый сервер, затем по одному действующему узлу с проверкой между шагами.
5. Завершение. Обновить фильтры сети, внутренний DNS, мониторинг и полные матрицы тестов.

Что делает генератор конфигурации

В генераторе хранится только открытый инвентарь. Для каждой пары он назначает отдельный if_id XFRM и пару транзитных адресов, определяет инициатора IKE с учётом NAT, создаёт два BGP-соседства и ограничивающие списки префиксов. На выходе для каждого узла получаются скрипт создания mesh0 и XFRM, unit systemd, конфигурации StrongSwan и FRR, а также два сценария перехода от старой адресации к маршрутам BGP.

Генератор не перенумеровывает существующие пары: для нового узла они добавляются в конец, а прежние if_id сохраняются. После генерации проверяются синтаксис Python и разница файлов; неожиданное изменение номера XFRM останавливает развёртывание.

from itertools import combinations

node_ids = [1, 2, 3, 4, 5]  # узел 5 добавлен последним
legacy_ids = [node_id for node_id in node_ids if node_id <= 4]

pair_order = list(combinations(legacy_ids, 2))
pair_order += [
    pair for pair in combinations(node_ids, 2)
    if pair not in pair_order
]

for pair_no, (left, right) in enumerate(pair_order, start=1):
    pairs[(left, right)] = {
        "if_id": 1000 + pair_no,
        "ifname": f"xfrm{left}{right}",
    }

Выпуск, перевыпуск и отзыв доступа

Узловой сертификат выпускается собственной CA по публичной части ключа. В нём проверяются имя узла в subject и SAN, издатель, срок и назначения serverAuth/clientAuth. Закрытый ключ CA остаётся только на выделенном административном узле; на сервер передаются его собственный сертификат и открытый сертификат CA.

# На новом узле: закрытый ключ не покидает сервер
umask 077
pki --gen --type ecdsa --size 256 > node-key.pem
pki --pub --type ecdsa --in node-key.pem > node-public.pem

# На узле CA: выпуск по переданной публичной части
pki --issue --type pub --in node-public.pem \
  --cacert mesh-ca.pem --cakey mesh-ca-key.pem \
  --dn "CN=node-e.mesh.example, O=Mesh" \
  --san node-e.mesh.example \
  --flag serverAuth --flag clientAuth --lifetime 825 \
  > node-certificate.pem

pki --print --in node-certificate.pem

Перевыпуск выполняется как поэтапная замена, а не как перезапись действующего файла. На узле создаются ключ и сертификат с суффиксом .next, текущая пара сохраняется с временной меткой, затем StrongSwan перечитывает реквизиты и соединения. После этого по одной переустанавливаются и проверяются IPsec SA; только успешная полная проверка позволяет убрать резервную копию. Для смены самой CA нужен период перекрывающегося доверия: новый корень сначала получают все узлы, затем меняются узловые сертификаты, и лишь после проверки удаляется старый корень.

При исключении или компрометации узла доступ прекращается сразу на уровне всех механизмов доверия: удаляются WireGuard peer, соединение StrongSwan, BGP-соседство и его префикс, правила разрешения публичного адреса и запись DNS. Закрытые ключи удаляются только на исключаемом сервере после проверки оставшейся сети.

Ранбук как часть реализации

После внедрения я оформил отдельный эксплуатационный ранбук. В нём зафиксированы:

• описание нормального состояния и ожидаемые числа соседей, туннелей и маршрутов;
• порядок запуска после перезагрузки и проверка зависимостей systemd;
• плановое обслуживание WireGuard, IPsec, FRR и внутреннего DNS;
• контролируемое переключение одной пары с обязательной прикладной проверкой;
• добавление и исключение узла без перенумерации действующих XFRM-интерфейсов;
• ротация ключей и сертификатов, диагностика и явный порядок отката;
• проверка мониторинга через временные правила с гарантированной очисткой.

Отдельно описан неприятный класс ошибок запуска: локальные интерфейсы должны появиться до WireGuard, StrongSwan, FRR и Docker, но не образовывать цикл через network-online.target. Без этого IPsec SA может выглядеть установленной, хотя XFRM-интерфейса для передачи трафика нет.