Įstrigęs VPN po maršrutizatoriaus perkrovimo: trys dalykai, kurie pasikeitė

Maršrutizatorius baigia krautis, nešiojamasis kompiuteris vėl prisijungia prie to paties SSID, o VPN lieka būsenoje prisijungta niekam nesijudant. Išsaugotas profilis nepažeistas. Tai, kas po juo pasibaigė, buvo kelias, o klientas vis dar laiko būseną, kurią sukūrė senajam.

Sprendimą lemia trys sąlygos. Tikrinkite jas iš eilės, nes vėlesnės yra bergždžias darbas, jei pirmoji jau paaiškina sustojimą.

Pirmoji sąlyga: vietinis adresas pasikeitė

Perkrovimas gali suteikti įrenginiui kitą adresą. Tada VPN, sukonfigūruotas su fiksuotu vietiniu galiniu tašku, toliau naudoja prisijungimą, kurio nebėra. Tas pats galioja klientui, kuris prisirišo savo lizdą prie seno adreso. Tunelio sąsaja gali likti aktyvi, nors kiekvienas jos sugeneruotas paketas keliauja į niekur.

Palyginkite adresą, kurį naudoja klientas, su adresu, kurį sąsaja turi dabar. Numatytoji trasa, rodanti į šliuzą, kuris taip pat pasikeitė, yra ta pati problema kitu vardu.

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

Antroji sąlyga: išverstas susiejimas dingo

Namų maršrutizatoriai verčia išeinančius srautus, o tie susiejimai gyvena atmintyje. Perkrovimas ištrina kiekvieną jų. Tai nekenksminga naujam ryšiui ir pražūtinga tuneliui, kuris tiki, kad jo esamas srautas vis dar galioja. Tada kita pusė nieko nemato, todėl klientas niekada negauna klaidos, pagal kurią galėtų veikti.

Čia tunelis be keepalive tyliai sustoja, o ne garsiai žlunga. „WireGuard“ dokumentuoti apribojimai aprašo tą pačią gedimo formą. Netinkama galinio taško būsena sukuria išmestus paketus, o ne diagnostiką.

Nuolatinis 25 sekundžių keepalive yra įprasta švelninimo priemonė, nes atnaujina susiejimą prieš pasibaigiant neveiklos skirtajam laikui. Tačiau jis nesutaiso susiejimo, kuris jau dingo. Poruokite keepalive su prisijungimo iš naujo logika, o ne laikykite jo sprendimu.

Trečioji sąlyga: viešasis adresas pasikeitė

Jei pasikeitė paties maršrutizatoriaus išorinis adresas, viskas kitoje pusėje, kas filtruoja pagal šaltinio adresą, dabar mato kitą partnerį. Tunelis gali pakilti, o serveris vis tiek gali atmesti srautą; tai atrodo kaip sugedęs klientas, o iš tikrųjų yra politika kitame gale.

Užsirašykite išorinį adresą prieš perkrovimą ir po jo. Kai jie skiriasi, klausimas persikelia nuo kliento prie to, kas prižiūri leidžiamų sąrašą, o prisijungimo duomenų nustatymas iš naujo nešiojamajame kompiuteryje negali padėti.

Atkurkite teisinga tvarka

Pirmiausia užbaikite visą reikalingą prisijungimą prie captive portalo, tada leiskite klientui vėl prisijungti jo palaikoma procedūra, o ne žudykite procesą. Stebėkite, ar atsistato ir tapatybė, ir duomenų srautas, nes tai du skirtingi to paties ryšio etapai.

Talpykloje saugomas puslapis nieko neįrodo, kaip ir pokalbių programa, kuri prisijungė pati. Išbandykite galinį tašką, kuris jums tikrai rūpi, nauja užklausa. Pertraukimo metu palikite galioti tiesioginio srauto politiką, nes bandymas prisijungti iš naujo nėra blokavimas.

Kai tai kartojasi po kiekvieno perkrovimo, įrašas svarbesnis už pakartojimą. Užsirašykite vietinį adresą, šliuzą, išorinį adresą ir kliento būseną prieš ir po, tada palyginkite du stulpelius. Tai paverčia neaiškų skundą gyvavimo ciklo klaida, kurią kas nors gali ištaisyti, ir sustabdo trečią sertifikatų keitimą dėl susiejimo skirtojo laiko.