Завислий 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-портал, потім дайте клієнту перепідключитися його підтримуваною процедурою, а не вбивайте процес. Стежте, чи відновлюються і ідентичність, і трафік даних, бо це дві різні стадії одного з'єднання.

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

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