Skip to main content

04 — Failover точки входа

Что происходит, когда региональная точка входа падает, и как клиент восстанавливается. Целевой RTO — минуты (секундный failover не требуется), это разрешает простые механизмы.

Сначала — два разных сценария​

Не путать:

  • Падение одной точки входа (intra-region). В регионе несколько роутеров-кандидатов на роль точки входа; control plane продвигает другой. Клиент остаётся в том же регионе. Это частый, «штатный» сбой — его и решаем прозрачно.
  • Потеря всего региона (cross-region). Клиента приходится перекидывать в другой регион — а это уже полноценная миграция (новый pool-IP, серверный ключ, регион) из модели B, т.е. ре-пуш конфига/подписки. Событие редкое и катастрофическое, более медленный путь приемлем.

Дальше — про intra-region, где и живёт основная логика failover.

Почему VIP/VRRP здесь не работает​

Соблазн «держать стабильный IP точки входа и перекидывать его на резерв» (VRRP/floating IP) разбивается о то, что клиенты бьются в публичный endpoint через интернет, а магазины географически распределены. Плавать публичным IP между магазинами без собственного PI-блока и BGP на уровне ISP нельзя. Поэтому рычаг — DNS, а не VIP.

Механизм 1 — DNS-failover (низкий TTL)​

База:

  • Endpoint у клиента — hostname, не IP (например r5a.vpn.corp), на низком TTL (PowerDNS).
  • Падение точки входа → control plane перекидывает A-запись на публичный IP новой точки входа.
  • Клиент перерезолвит имя при попытке переподключения и встанет на новый адрес.

Чтобы это сработало прозрачно, новая точка входа должна:

  1. предъявлять ТОТ ЖЕ серверный WG-pubkey — иначе Peer PublicKey в конфиге клиента не сойдётся, handshake провалится, и ты вылетишь в медленный ре-пуш. → на роутерах-кандидатах региона предзашит один и тот же WG private key (на ROSv7 это настраиваемый ключ интерфейса). Мягкий security-tradeoff (ключ на N коробках), но в пределах регионального trust-boundary ок; ты сам решаешь, какие роутеры — кандидаты.
  2. уже иметь пиры клиентов — control plane держит peer-листы кандидатов синхронными заранее, а не наливает их в момент аварии.

Поведение ре-резолва по платформам (важно)​

  • WireGuard-app на iOS/Android — перерезолвят hostname сами при неуспешном хендшейке. Для них DNS-failover автоматический.
  • kernel-WG на Linux/Windows — резолвит endpoint один раз при загрузке конфига и сам не перечитывает. Нужен хелпер reresolve-dns (есть в contrib к wireguard-tools) по таймеру.
  • sing-box — поведение перерезолва WG-пира с DNS-именем нужно проверить на своей версии; если резолвит один раз, как kernel-WG, DNS-failover на sing-box-клиенте сам не сработает. Тогда используй механизм 2.

Механизм 2 — client-side failover (sing-box urltest)​

Если клиент на sing-box (файл 05), есть более прямой путь, не зависящий от ре-резолва DNS: положить в профиль несколько точек входа региона как отдельные WG-endpoint'ы и сгруппировать их в urltest. sing-box периодически щупает задержку до каждой и переключается на живую; interrupt_exist_connections: true форсирует переезд активных соединений.

  • Плюс: failover решается на клиенте, без DNS-ре-резолва и без обязательного общего ключа.
  • Цена: профиль несёт пиры (и pubkey-и) всех кандидатов, и все они должны быть предзаготовлены.

Механизм 3 — детект скорости падения (persistent_keepalive)​

Любой механизм бесполезен, пока клиент не заметил, что точка входа мертва. PersistentKeepalive ~25s заставляет клиента слать пакет каждые 25 секунд; когда они начнут теряться, клиент быстрее пойдёт в retry/ре-резолв. Без keepalive простаивающий клиент не заметит смерть, пока сам не пошлёт трафик. Ставь keepalive на всех клиентских конфигах.

Что с RTO​

При DNS-failover + keepalive=25 + низкий TTL + retry хендшейка WireGuard (~5s) восстановление — десятки секунд, и это без единого касания MDM. Так как нам достаточно «минут», запас большой. MDM/подписка остаются только для cross-region (катастрофа) и первичной выдачи.

На пальцах: рецепт для intra-region failover​

  1. Endpoint клиента — hostname на низком TTL (PowerDNS).
  2. Роутеры-кандидаты региона делят один WG-серверный ключ.
  3. Пиры клиентов предзалиты на всех кандидатов (control plane синхронит).
  4. persistent_keepalive ~25 на клиентах.
  5. Control plane при падении: перекинул A-запись (DNS) ИЛИ полагаемся на urltest (sing-box).
  6. Telegram-ассистент уведомляет о факте миграции/переключения.

Грабли​

  • Не пытайся плавать публичным VIP между магазинами — рычаг это DNS.
  • Серверный pubkey на кандидатах должен совпадать, иначе handshake не пройдёт.
  • Проверь ре-резолв DNS на конкретном клиенте; для sing-box рассмотри urltest как замену.
  • Без keepalive failover «срабатывает», но поздно.