Заглавен 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 порталот, потоа оставете клиентот да се поврзе повторно по неговата поддржана постапка наместо да го убиете процесот. Гледајте дали се враќаат и идентитетот и податочниот сообраќај, зашто тоа се два различни степени на истата врска.

Кешираната страница не докажува ништо, како и апликацијата за разговор што сама се поврза повторно. Тестирајте ја крајната точка што навистина ви е важна со ново барање. Задржете ја политиката за директен сообраќај за време на прекинот, зашто обидот за повторно поврзување не е блокирање.

Кога ова се повторува по секој рестарт, записот е поважен од обидот. Забележете ја локалната адреса, портата, надворешната адреса и состојбата на клиентот пред и по, па споредете ги двете колони. Тоа ја претвора нејасната жалба во грешка во животниот циклус што некој може да ја поправи и ја запира третата замена на сертификатите поради тајмаут на мапирањето.