Залипший VPN после перезагрузки роутера: три вещи, которые изменились

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

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

Исправление определяют три условия. Проверяйте их по порядку, потому что последующие — пустая трата сил, если первое уже объясняет остановку.

Условие первое: локальный адрес изменился

Перезагрузка может выдать машине другой адрес. Тогда VPN, настроенный с фиксированной локальной конечной точкой, продолжает использовать привязку, которой больше нет. То же относится к клиенту, который привязал свой сокет к старому адресу. Интерфейс туннеля может оставаться поднятым, пока каждый созданный им пакет уходит в никуда.

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

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Условие второе: транслированное сопоставление исчезло

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

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

Постоянный keepalive в 25 секунд — обычное смягчение, потому что он обновляет сопоставление до истечения тайм-аута простоя. Он не чинит сопоставление, которое уже исчезло. Сочетайте keepalive с логикой переподключения, а не считайте его исправлением.

Условие третье: публичный адрес изменился

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

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

Восстанавливайте в правильном порядке

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

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

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

Похожие статьи