IP-адрес WAN изменился, а туннель упал: проверки по порядку

Туннель падает, роутер фиксирует переподключение, а в локальной сети ничего не сдвинулось. Новый адрес WAN делает внешнее соединение недействительным, ничего не меняя внутри: адрес источника клиента изменился, старое состояние NAT указывает на источник, которого больше нет, а удалённый пир может по-прежнему отправлять на прежний адрес. Восстановление — нормальное поведение, и полезный вопрос в том, какое состояние не обновилось.

Назовите событие, прежде чем читать журнал

Проверьте, что на самом деле произошло на уровне доступа. Продление аренды у провайдера — одно событие. Сессия PPPoE, которая переподключилась, — другое. Перезагруженный оптический модем или переключение WAN с одного канала на другой меняет внешний адрес или его путь третьим способом. Это не одно и то же событие, и они не оставляют одинаковый остаток.

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

Роуминг и переподключение — разные протоколы

В WireGuard аутентифицированный роуминг встроен в протокол: когда пир получает корректно аутентифицированный пакет с нового адреса источника, он обновляет конечную точку этого пира. Краткое руководство WireGuard описывает конфигурацию пира, которая это обеспечивает, поэтому клиент на меняющемся адресе часто восстанавливается без видимого перезапуска.

OpenVPN по умолчанию ведёт себя иначе. Сессия UDP может завершиться и переподключиться, а необязательное поведение float позволяет аутентифицированному пиру продолжить с нового адреса там, где это разрешает конфигурация. Туннели на основе TCP строже, потому что само соединение привязано к паре адресов. Эта разница решает, будет ли восстановление выглядеть незаметным или каждый раз объявлять о себе в журнале.

Ни одно из поведений ничего не говорит о приложениях внутри. Восстановленный туннель не восстанавливает сессию TCP, которую пир уже считал мёртвой.

Состояние, которым туннель не владеет

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

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

Упорядочьте проверки снаружи внутрь

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

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

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

Затем проверяйте с клиента локальной сети, а не с роутера. Ping отправленный самим роутером использует другой путь, чем пересылаемый трафик, поэтому успешный ping с роутера доказывает существование туннеля и ничего не говорит о доступности клиента.

Определите ожидаемое поведение и запишите его

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

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