Заседнал VPN след рестарт на рутера: три неща, които се промениха

Профилът не се промени, но пътят под него се промени. Проверете локалния адрес, преведения mapping и маршрута, преди да нулирате идентификационните данни.

Рутерът завършва зареждането, лаптопът се присъединява към същия SSID, а VPN-ът стои в състояние свързан, без нищо да се движи. Запазеният профил е непокътнат. Това, което е изтекло под него, е пътят, и клиентът все още държи състоянието, което е изградил за стария.

Поправката се определя от три условия. Проверявайте ги по ред, защото следващите са излишен труд, ако първото вече обяснява застоя.

Условие първо: локалният адрес се е променил

Рестартът може да даде на машината друг адрес. Тогава VPN, конфигуриран с фиксирана локална крайна точка, продължава да използва връзка, която вече не съществува. Същото важи за клиент, който е обвързал сокета си със стария адрес. Тунелният интерфейс може да остане активен, докато всеки пакет, който произвежда, отива наникъде.

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

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

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

Домашните рутери превеждат изходящите потоци и тези mapping-и живеят в паметта. Рестартът изчиства всеки един от тях. Това е безвредно за нова връзка и фатално за тунел, който вярва, че съществуващият му поток е още валиден. Тогава отсрещната страна не вижда нищо и клиентът никога не получава грешка, с която да работи.

Тук тунел без keepalive застоява тихо, вместо да се провали шумно. Документираните ограничения на WireGuard описват същата форма на провал. Грешно състояние на крайната точка дава изхвърлени пакети, а не диагностика.

Постоянен keepalive от 25 секунди е обичайното смекчаване, защото опреснява mapping-а, преди да изтече таймаутът на бездействие. Той не поправя mapping, който вече е изчезнал. Свържете keepalive с логика за повторно свързване, вместо да го третирате като поправка.

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

Ако собственият външен адрес на рутера се е променил, всичко от другата страна, което филтрира по адрес на източника, вече вижда друг партньор. Тунелът може да се вдигне, а сървърът все още да изхвърля трафика; това изглежда като счупен клиент, а всъщност е политика от другата страна.

Запишете външния адрес преди и след рестарта. Когато двата се различават, въпросът се мести от клиента към този, който поддържа списъка с разрешени, и нулирането на идентификационните данни на лаптопа не може да помогне.

Възстановявайте в правилния ред

Първо завършете изискуемия вход през captive portal, после оставете клиента да се свърже отново по поддържаната процедура, вместо да убивате процеса. Наблюдавайте дали се възстановяват и идентичността, и трафикът на данни, защото това са два различни етапа на една и съща връзка.

Кеширана страница не доказва нищо, нито чат приложение, което се е свързало само. Тествайте крайната точка, която наистина ви интересува, с нова заявка. Поддържайте политиката за директен трафик по време на прекъсването, защото опитът за повторно свързване не е блокиране.

Когато това се повтаря след всеки рестарт, записът има по-голямо значение от повторението. Отбележете локалния адрес, шлюза, външния адрес и състоянието на клиента преди и след, после сравнете двете колони. Това превръща неясно оплакване в грешка в жизнения цикъл, която някой може да поправи, и спира третата подмяна на сертификатите заради таймаут на mapping.

Подобни статии