Jumissa oleva VPN reitittimen uudelleenkäynnistyksen jälkeen: kolme asiaa, jotka muuttuivat

Reititin saa käynnistyksen valmiiksi, kannettava liittyy uudelleen samaan SSID:hen ja VPN jää yhdistetty-tilaan ilman että mikään liikkuu. Tallennettu profiili on ehjä. Sen alla vanheni polku, ja asiakas pitää yhä kiinni tilasta, jonka se rakensi vanhaa varten.

Korjauksen ratkaisee kolme ehtoa. Tarkista ne järjestyksessä, sillä myöhemmät ovat hukattua työtä, jos ensimmäinen jo selittää pysähdyksen.

Ehto yksi: paikallinen osoite on muuttunut

Uudelleenkäynnistys voi antaa koneelle eri osoitteen. Silloin kiinteällä paikallisella päätepisteellä määritetty VPN jatkaa liitoksen käyttöä, jota ei enää ole. Sama koskee asiakasta, joka sitoi socketinsa vanhaan osoitteeseen. Tunneliliitäntä voi pysyä ylhäällä, vaikka jokainen sen tuottama paketti menee hyödyttömään paikkaan.

Vertaa asiakkaan käyttämää osoitetta liitännän nykyiseen osoitteeseen. Oletusreitti, joka osoittaa myös muuttuneeseen yhdyskäytävään, on samaa ongelmaa toisella nimellä.

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

Ehto kaksi: käännetty mappaus on kadonnut

Kotireitittimet kääntävät lähteviä virtauksia, ja ne mappaukset elävät muistissa. Uudelleenkäynnistys pyyhkii jokaisen niistä. Se on uudelle yhteydelle harmitonta ja tuhoisaa tunnelille, joka uskoo nykyisen virtauksensa olevan yhä kelvollinen. Silloin vastapuoli ei näe mitään, joten asiakas ei koskaan saa virhettä, jonka pohjalta toimia.

Tässä tunnelma ilman keepalivea pysähtyy hiljaa sen sijaan että epäonnistuisi äänekkäästi. WireGuardin dokumentoidut rajoitukset kuvaavat saman epäonnistumisen muodon. Väärä päätepisteen tila tuottaa pudotettuja paketteja diagnoosin sijaan.

Pysyvä 25 sekunnin keepalive on tavallinen lievennys, koska se päivittää mappauksen ennen kuin joutokäynnin aikakatkaisu voi umpeutua. Se ei korjaa mappausta, joka on jo kadonnut. Yhdistä keepalive uudelleenyhdistämislogiikkaan sen sijaan että pitäisit sitä korjauksena.

Ehto kolme: julkinen osoite on muuttunut

Jos reitittimen oma ulkoinen osoite on muuttunut, kaikki toisella puolella lähdeosoitteen mukaan suodattava näkee nyt toisen vastapuolen. Tunneli voi nousta ja palvelin voi silti hylätä liikenteen; se näyttää rikkinäiseltä asiakkaalta ja on todella käytäntö toisessa päässä.

Kirjaa ulkoinen osoite ennen uudelleenkäynnistystä ja sen jälkeen. Kun ne eroavat, kysymys siirtyy asiakkaalta sille, joka ylläpitää sallittujen listaa, eikä tunnistetietojen nollaaminen kannettavassa voi auttaa.

Palauta oikeassa järjestyksessä

Suorita ensin mahdollinen pakollinen captive-portaalin kirjautuminen, anna sitten asiakkaan yhdistää uudelleen tuetulla menettelyllään sen sijaan että tappaisit prosessin. Seuraa palautuvatko sekä identiteetti että dataliikenne, sillä ne ovat saman yhteyden kaksi eri vaihetta.

Välimuistiin tallennettu sivu ei todista mitään, eikä chat-sovellus, joka yhdisti itse uudelleen. Testaa päätepiste, josta todella välität, tuoreella pyynnöllä. Pidä suoran liikenteen käytäntö voimassa katkoksen ajan, sillä uudelleenyhdistämisyritys ei ole esto.

Kun tämä toistuu jokaisen uudelleenkäynnistyksen jälkeen, kirjaus on tärkeämpi kuin uusi yritys. Merkitse paikallinen osoite, yhdyskäytävä, ulkoinen osoite ja asiakkaan tila ennen ja jälkeen ja vertaa sitten kahta saraketta. Se muuttaa epämääräisen valituksen elinkaarivirheeksi, jonka joku voi korjata, ja se estää sertifikaattien kolmannen vaihdon mappauksen aikakatkaisun takia.