Ali VPN pade po obnovitvi DHCP? Primerjajte naslove

Obnovitev najema in okvara VPN se v dnevnikih pojavljata skupaj dovolj pogosto, da ljudje sklepajo, da eno povzroča drugo. Časovno ujemanje je resnično; vzročnost običajno ne. Obnovitev je enonaslovna zahteva strežniku, ki je izdal najem, za nadaljevanje iste vezave, in strežnik jo lahko podaljša, ne da bi odjemalec spremenil en sam naslov. Pregled lastnih vrednosti odjemalca okoli dogodka loči tiho obnovljen najem od omrežja, ki se je zares spremenilo pod delujočim tunelom.

Začnite pri odjemalcu, ki je padel

Najprej odprite dnevnik povezav odjemalca in zapišite čas izpada na sekundo natančno. Nato odprite omrežni dnevnik operacijskega sistema za isto minuto in po vrsti preberite, kaj je počel vmesnik. Ta vrstni red je cela preiskava: dogodek DHCP pred prekinitvijo, prekinitev pred dogodkom DHCP in dva dogodka brez ničesar med njima so tri različne ugotovitve. Vrstica dnevnika, ki le omenja najem, medtem ko se je tunel že znova povezoval, je dekoracija, ne dokaz.

Časovnico zapisujte sproti, namesto da bi jo držali v spominu. Časovni žigi različnih orodij se redko ujemajo popolnoma, in sama razlika je včasih razlaga.

Primerjajte štiri vrednosti okoli dogodka

Štiri vrednosti dovolj dobro opisujejo lokalno stran povezave, da ujamejo resnično spremembo: naslov vmesnika, privzeti prehod, seznam resolverjev in delovno stanje vmesnika. Zabeležite jih v minuti po izpadu in primerjajte s posnetkom, narejenim, ko je bil tunel zdrav.

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

Nespremenjen naslov z nespremenjenim prehodom in spremenjenim seznamom resolverjev kaže na razreševanje imen, ne na usmerjanje, in tunel je morda preživel, medtem ko so aplikacije prenehale najti gostitelje. Spremenjen prehod pomeni, da se je pot iz lokalnega omrežja premaknila, kar zadošča za razveljavitev poti, ki je kazala na prejšnjo. Če se vse štiri vrednosti ujemajo z zdravim posnetkom, najem ni vaš vzrok in tema postane lastna logika ponovnega povezovanja odjemalca. Posnetek primerjave zajemite, dokler je napaka vidna, ker ima zdrav posnetek po ponovnem zagonu drugačno zgodovino naslovov in se ne bo ujemal.

Kaj obnovitev lahko in česa ne more spremeniti

RFC 2131 opisuje obnovitev kot zahtevo prvotnemu strežniku na polovici časa najema, s ponovno vezavo na kateri koli strežnik pri sedmih osminah, če prvi poskus ostane brez odgovora. Noben korak ne zahteva, da odjemalec pridobi drug naslov, in sodelujoči strežnik običajno podaljša obstoječo vezavo. Resnična sprememba naslova običajno pride po drugi poti: strežnik zavrne obnovitev, odjemalec je izgubil svoje stanje in začel znova, ali omrežje premakne napravo v drug segment.

Javna stran povezave se lahko spremeni brez kakršne koli lokalne spremembe. Za prevajanjem na ravni operaterja se naslov, ki ga vidi partner VPN, lahko prerazporedi neodvisno od tega, kar je storil lokalni najem, in ta prerazporeditev je od znotraj odjemalca videti enako kot lokalna omrežna okvara. Primerjava lokalno sporočenega naslova z opažanjem na strani partnerja je edini način, da ju ločimo.

Ko se odjemalec ne more prilagoditi

Odjemalec, ki je svoj transport vezal na stari naslov, predpomnil zastarelo pot do partnerja ali shranil identiteto vmesnika, lahko še naprej poskuša pot, ki ne obstaja več. To je napaka pri prilagajanju in se kaže kot ponavljajoča se ponovna pošiljanja na naslov, do katerega gostitelj ne more več priti. Nekateri odjemalci to rešujejo po zasnovi: WireGuard na primer posodobi končno točko partnerja, ko z novega vira prispe pravilno overjen paket.

Ročni ponovni zagon, ki obnovi storitev, je namig, kje je prilagajanje spodletelo, ne dokaz, da so najemi in tuneli nezdružljivi. Med preizkušanjem pustite politiko blokiranja v veljavi, sicer preizkus sam postane izpad z drugim vzrokom. Zabeležite, ali si je odjemalec opomogel sam, koliko časa je trajalo in kateri naslov je poskusil znova; to zaporedje vam pove več kot razlog prekinitve, prikazan v vmesniku.

Ponovite dogodek, preden ga krivite

Ponovno ustvarite pogoj, namesto da čakate na urnik: sprostite in obnovite najem ali vsilite enakovreden nadzorovani dogodek in opazujte, ali tunel preživi. V upravljanem omrežju uskladite vsako spremembo naslova z lastnikom omrežja, ker lahko poljubna statična dodelitev trči ob napravo, ki ta naslov že ima.

Po podprtem popravku ponovite isti dogodek in nato preizkusite aplikacijo in poizvedbo imena, ker tunel, ki se znova poveže, a pokvari DNS, opravi šibkejši preizkus od tistega, ki šteje. Poročajte o konkretni opaženi spremembi z njeno časovno oznako, namesto da bi načrtovani najem navedli kot vzrok. Razlika med tema dvema poročiloma je, ali lahko naslednja oseba ponovi napako ali le govorico.