Putoaako VPN DHCP-uudistuksen jälkeen? Vertaa osoitteita

Vuokrasopimuksen uudistus ja VPN:n vikaantuminen esiintyvät lokeissa yhdessä niin usein, että ihmiset päättelevät toisen aiheuttavan toisen. Ajoitus on todellinen; syy-yhteys yleensä ei. Uudistus on yksilähetyspyyntö vuokrasopimuksen myöntäneelle palvelimelle, jossa pyydetään jatkamaan saman sidonnan käyttöä, ja palvelin voi pidentää sitä ilman, että asiakas muuttaa yhtäkään osoitetta. Asiakkaan omien arvojen tarkastelu tapahtuman ympärillä erottaa hiljaa uudistuneen vuokrasopimuksen verkosta, joka todella muuttui käynnissä olevan tunnelin alla.

Aloita asiakkaasta, joka putosi

Avaa ensin asiakkaan yhteysloki ja kirjaa katkoksen aika sekunnin tarkkuudella. Avaa sitten käyttöjärjestelmän verkkoloki samalta minuutilta ja lue järjestyksessä, mitä liitäntä teki. Tämä järjestys on koko tutkinta: DHCP-tapahtuma ennen yhteyden katkeamista, katkeaminen ennen DHCP-tapahtumaa ja kaksi tapahtumaa ilman mitään niiden välissä ovat kolme eri havaintoa. Lokirivi, joka vain mainitsee vuokrasopimuksen tunnelin jo yhdistyessä uudelleen, on koristetta, ei todiste.

Kirjoita aikajana sitä mukaa kun etenet sen sijaan että pitäisit sitä muistissa. Eri työkalujen aikaleimat osuvat harvoin täsmälleen yhteen, ja itse ero on joskus selitys.

Vertaa tapahtuman ympärillä olevia neljää arvoa

Neljä arvoa kuvaavat yhteyden paikallista puolta tarpeeksi hyvin todellisen muutoksen havaitsemiseksi: liitännän osoite, oletusyhdyskäytävä, ratkaisijoiden luettelo ja liitännän toimintatila. Ota ne minuutin kuluessa katkoksesta ja vertaa tallenteeseen, joka tehtiin tunnelin ollessa terve.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Muuttumaton osoite, muuttumaton yhdyskäytävä ja muuttunut ratkaisijoiden luettelo viittaavat nimien ratkaisuun eikä reititykseen, ja tunneli on voinut selvitä, kun sovellukset lakkasivat löytämästä isäntiä. Muuttunut yhdyskäytävä tarkoittaa, että paikallisesta verkosta ulos johtava polku siirtyi, mikä riittää mitätöimään reitin, joka osoitti edelliseen. Jos kaikki neljä arvoa vastaavat tervettä tallennetta, vuokrasopimus ei ole syysi ja asiakkaan oma uudelleenyhdistämislogiikka tulee aiheeksi. Ota vertailu, kun vika on näkyvissä, sillä uudelleenkäynnistyksen jälkeen tehdyssä terveessä tallenteessa on erilainen osoitehistoria eikä se vastaa.

Mitä uudistus voi ja mitä ei voi muuttaa

RFC 2131 kuvaa uudistuksen pyyntönä alkuperäiselle palvelimelle puolessa vuokra-ajasta, uudelleensidonnalla mihin tahansa palvelimeen seitsemässä kahdeksasosassa, jos ensimmäinen yritys jää vastaamatta. Kumpikaan vaihe ei vaadi asiakasta hankkimaan eri osoitetta, ja yhteistyöhaluinen palvelin yleensä pidentää olemassa olevaa sidontaa. Todellinen osoitteenmuutos tulee yleensä toista kautta: palvelin kieltäytyy uudistuksesta, asiakas menetti tilansa ja aloitti alusta, tai verkko siirsi laitteen toiseen segmenttiin.

Yhteyden julkinen puoli voi muuttua ilman mitään paikallista muutosta. Operaattoritason käännöksen takana osoite, jonka VPN-vastapuoli näkee, voidaan osoittaa uudelleen riippumatta siitä, mitä paikallinen vuokrasopimus teki, ja tämä uudelleenosoitus näyttää asiakkaan sisältä samalta kuin paikallinen verkkohäiriö. Paikallisesti raportoidun osoitteen vertaaminen vastapuolen havaintoon on ainoa tapa erottaa ne.

Kun asiakas ei sopeudu

Asiakas, joka sitoi kuljetuksensa vanhaan osoitteeseen, välimuistiin vanhentuneen reitin vastapuolelle tai tallensi liitännän identiteetin, voi jatkaa polun yrittämistä, jota ei enää ole. Se on sopeutumisvirhe, ja se näkyy toistuvina uudelleenlähetyksinä osoitteeseen, johon isäntä ei enää pääse. Jotkut asiakkaat hoitavat sen suunnitellusti: esimerkiksi WireGuard päivittää vastapuolen päätepisteen, kun oikein todennettu paketti saapuu uudesta lähteestä.

Palvelun palauttava manuaalinen uudelleenkäynnistys on vihje siitä, missä sopeutuminen epäonnistui, ei todiste siitä, että vuokrasopimukset ja tunnelit eivät sovi yhteen. Pidä estokäytäntö voimassa testin aikana, muuten testistä itsestään tulee eri syystä johtuva katkos. Kirjaa, toipuiko asiakas itsestään, kauanko se kesti ja mitä osoitetta se yritti uudelleen; tämä järjestys kertoo sinulle enemmän kuin liitännässä näkyvä katkeamisen syy.

Toista tapahtuma ennen kuin syytät sitä

Toisinna ehto sen sijaan että odottaisit aikataulua: vapauta ja uudista vuokrasopimus tai pakota vastaava hallittu tapahtuma, ja seuraa, selviääkö tunneli. Hallitussa verkossa sovita kaikki osoitemuutokset verkon omistajan kanssa, sillä mielivaltainen staattinen osoitus voi törmätä laitteeseen, jolla on jo kyseinen osoite.

Tuetun korjauksen jälkeen toista sama tapahtuma ja testaa sitten sovellus ja nimikysely, sillä tunneli, joka yhdistyy uudelleen mutta rikkoo DNS:n, läpäisee heikomman testin kuin se, jolla on merkitystä. Raportoi havaitsemasi konkreettinen muutos aikaleimoineen sen sijaan että nimeäisit aikataulun mukaisen vuokrasopimuksen syyksi. Näiden kahden raportin ero on siinä, voiko seuraava henkilö toisintaa vian vai vain huhun.