VPN pada nakon obnove DHCP-a? Usporedite adrese

Obnova najma i pad VPN-a dovoljno često se pojavljuju zajedno u zapisima da ljudi zaključe kako jedno uzrokuje drugo. Vremensko podudaranje je stvarno; uzročnost obično nije. Obnova je jednoodredišni zahtjev poslužitelju koji je izdao najam, kojim se traži nastavak korištenja iste veze, a poslužitelj je može produžiti bez da klijent promijeni ijednu adresu. Razmatranje klijentovih vlastitih vrijednosti oko događaja odvaja najam koji se tiho obnovio od mreže koja se doista promijenila pod tunelom koji radi.

Počnite od klijenta koji je pao

Najprije otvorite klijentov zapis veze i zabilježite vrijeme prekida do sekunde. Zatim otvorite mrežni zapis operacijskog sustava za istu minutu i pročitajte redom što je sučelje učinilo. Taj redoslijed je cijela istraga: DHCP događaj prije prekida, prekid prije DHCP događaja i dva događaja bez ičega između tri su različita nalaza. Redak zapisa koji samo spominje najam dok se tunel već ponovno povezivao jest ukras, a ne dokaz.

Zapisujte vremensku crtu usput umjesto da je držite u pamćenju. Vremenske oznake različitih alata rijetko se savršeno poklapaju, a sam pomak katkad je objašnjenje.

Usporedite četiri vrijednosti oko događaja

Četiri vrijednosti dovoljno dobro opisuju lokalnu stranu veze da uhvate stvarnu promjenu: adresa sučelja, zadani pristupnik, popis razrješivača i radno stanje sučelja. Zabilježite ih unutar minute nakon prekida i usporedite sa snimkom načinjenom dok je tunel bio 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

Nepromijenjena adresa s nepromijenjenim pristupnikom i promijenjenim popisom razrješivača upućuje na razrješavanje imena, a ne na usmjeravanje, i tunel je mogao preživjeti dok su aplikacije prestale pronalaziti hostove. Promijenjen pristupnik znači da se put iz lokalne mreže pomaknuo, što je dovoljno da poništi rutu koja je pokazivala na prethodni. Ako sve četiri vrijednosti odgovaraju zdravoj snimci, najam nije vaš uzrok i tema postaje klijentova vlastita logika ponovnog povezivanja. Snimite usporedbu dok je kvar vidljiv, jer zdrava snimka načinjena nakon ponovnog pokretanja ima drukčiju povijest adresa i neće se poklopiti.

Što obnova može, a što ne može promijeniti

RFC 2131 opisuje obnovu kao zahtjev izvornom poslužitelju na polovici trajanja najma, s ponovnim povezivanjem na bilo koji poslužitelj na sedam osmina ako prvi pokušaj ostane bez odgovora. Nijedan korak ne zahtijeva da klijent dobije drugu adresu, a poslužitelj koji surađuje obično produljuje postojeću vezu. Stvarna promjena adrese obično dolazi drugim putem: poslužitelj odbija obnovu, klijent je izgubio svoje stanje i počeo iznova ili je mreža premjestila uređaj u drugi segment.

Javna strana veze može se promijeniti bez ikakve lokalne promjene. Iza prijevoda operatorske klase adresa koju VPN partner vidi može biti preraspodijeljena neovisno o bilo čemu što je lokalni najam učinio, a ta preraspodjela iznutra klijenta izgleda jednako kao lokalni mrežni kvar. Usporedba lokalno iskazane adrese s promatranjem na strani partnera jedini je način da ih razlučite.

Kada se klijent ne uspije prilagoditi

Klijent koji je svoj prijenos vezao uz staru adresu, predmemorirao zastarjelu rutu do partnera ili sačuvao identitet sučelja može nastaviti ponavljati put koji više ne postoji. To je nedostatak prilagodbe i vidi se kao ponovljena prenošenja prema adresi do koje host više ne može doći. Neki klijenti to rješavaju po dizajnu: primjerice WireGuard ažurira partnerovu završnu točku kada ispravno provjeren paket stigne s novog izvora.

Ručno ponovno pokretanje koje vraća uslugu trag je o tome gdje je prilagodba zakazala, a ne dokaz da su najam i tuneli nespojivi. Držite politiku blokiranja na mjestu tijekom testiranja, inače sam test postaje prekid s drugim uzrokom. Zabilježite je li se klijent oporavio sam, koliko je trajalo i koju je adresu ponovno pokušao; taj slijed govori vam više od razloga prekida prikazanog u sučelju.

Ponovite događaj prije nego što ga okrivite

Reproducirajte uvjet umjesto da čekate raspored: otpustite i obnovite najam ili izazovite istovjetni kontrolirani događaj i gledajte hoće li tunel preživjeti. Na upravljanoj mreži uskladite svaku promjenu adrese s vlasnikom mreže, jer proizvoljna statička dodjela može se sukobiti s uređajem koji tu adresu već drži.

Nakon podržanog ispravka ponovite isti događaj, a zatim testirajte aplikaciju i pretragu imena, jer tunel koji se ponovno povezuje, ali kvari DNS, prolazi slabiji test od onoga koji je važan. Prijavite konkretnu promjenu koju ste primijetili, s njezinom vremenskom oznakom, umjesto da planirani najam proglasite uzrokom. Razlika između tih dvaju izvješća jest može li sljedeća osoba reproducirati kvar ili samo glasinu.