WireGuard 5G в филиале: пусть филиал сам звонит в центр

Направить филиал на центр — это лёгкая половина такого решения, когда филиал находится за меняющимся мобильным адресом, а у центра есть стабильное имя. Тогда центр узнаёт филиал из аутентифицированного трафика, а не из записи, которую вам приходится поддерживать в актуальном виде. Договор прост: филиал всегда инициирует.

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

Какая сторона держит стабильную конечную точку

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

Когда филиал отправляет аутентифицированный пакет, центр записывает источник, откуда тот пришёл, и использует это сопоставление для ответов. Перенумерация мобильного канала тогда не стоит ничего, кроме следующего рукопожатия, и каждый компонент, который вам больше не нужен, — это тот, который не может отказать при переключении. Это свойство стоит проверять при плановом изменении, а не во время инцидента. Сделайте это, пока кто-то может смотреть на оба конца одновременно.

Дайте филиалу конфигурацию, которая переживает перенумерацию

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

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

Двадцать пять секунд — часто цитируемый пример для поддержания сопоставления NAT живым, а не требование для каждого партнёра. Задавайте его по тому таймауту сопоставления, который вы действительно наблюдаете, и помните, что он создаёт трафик на канале с лимитом данных, пока интерфейс включён.

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

Проверьте сопоставление и переключение

Убедитесь, что рукопожатие завершается, что центр перечисляет текущую конечную точку филиала и что внутренние адреса филиала доступны через туннель. Это базовая линия, и её стоит зафиксировать до того, как кто-либо тронет мобильный канал. Двух строк вывода достаточно. Храните их в заявке вместе с отметкой времени.

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

Затем проверьте отказ, для которого эта схема существует. Выдерните основной WAN и убедитесь, что нижележащий маршрут филиала к центру теперь выходит через мобильный интерфейс. Туннель не может починить разорванный физический путь, поэтому внешний маршрут, всё ещё указывающий на мёртвое восходящее соединение, даёт таймаут рукопожатия, который выглядит в точности как проблема центра.

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

Чего эта схема не решает

Здесь ничто не допускает входящего подключения к филиалу. Если что-то в головном офисе должно набирать мобильную площадку, направление туннеля для этого требования неверно, а динамический DNS обновляет только имя. Трансляция провайдера, входящая политика и обновление конечной точки клиентом — всё это остаётся на пути, и изменённая запись не может открыть NAT операторского уровня.

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

Запишите в runbook четыре вещи: кто инициирует, какие префиксы разрешены, как долго длится keepalive и что происходит, когда основной канал падает. Именно эти строки действительно нужны будущему оператору в три часа ночи.