VPN padá po obnovení DHCP? Porovnajte adresy

Obnovenie prenájmu a zlyhanie VPN sa v protokoloch objavujú spolu dosť často na to, aby ľudia usúdili, že jedno spôsobuje druhé. Časová zhoda je skutočná; príčinnosť zvyčajne nie. Obnovenie je jednosmerná požiadavka serveru, ktorý prenájom vydal, pokračovať v používaní toho istého zviazania, a server ho môže predĺžiť bez toho, aby klient zmenil jedinú adresu. Prejdenie vlastných hodnôt klienta okolo udalosti oddeľuje potichu obnovený prenájom od siete, ktorá sa pod bežiacim tunelom skutočne zmenila.

Začnite u klienta, ktorý vypadol

Najprv otvorte klientsky protokol pripojení a zapíšte čas výpadku na sekundu. Potom otvorte sieťový protokol operačného systému pre rovnakú minútu a prečítajte si v poradí, čo rozhranie robilo. Toto poradie je celé vyšetrovanie: udalosť DHCP pred odpojením, odpojenie pred udalosťou DHCP a dve udalosti bez ničoho medzi nimi sú tri rôzne zistenia. Riadok protokolu, ktorý len spomína prenájom, kým sa tunel už znovu pripájal, je dekorácia, nie dôkaz.

Zapisujte časovú os priebežne, namiesto toho, aby ste ju držali v pamäti. Časové pečiatky z rôznych nástrojov sa málokedy kryjú dokonale a samotný rozdiel je niekedy vysvetlením.

Porovnajte štyri hodnoty okolo udalosti

Štyri hodnoty opisujú lokálnu stranu spojenia dosť dobre na to, aby zachytili skutočnú zmenu: adresa rozhrania, predvolená brána, zoznam resolverov a prevádzkový stav rozhrania. Zachyťte ich do minúty po výpadku a porovnajte so záznamom zhotoveným, keď bol 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

Nezmenená adresa s nezmenenou bránou a zmeneným zoznamom resolverov ukazuje na preklad mien, nie na smerovanie, a tunel mohol prežiť, kým aplikácie prestali nachádzať hostiteľov. Zmenená brána znamená, že sa cesta z lokálnej siete posunula, čo stačí na zneplatnenie trasy, ktorá ukazovala na predchádzajúcu. Ak všetky štyri hodnoty zodpovedajú zdravému záznamu, prenájom nie je vaša príčina a témou sa stáva vlastná logika opätovného pripojenia klienta. Zachyťte porovnanie, kým je porucha viditeľná, pretože zdravý záznam zhotovený po reštarte má inú históriu adries a nebude zodpovedať.

Čo obnovenie môže a čo nemôže zmeniť

RFC 2131 opisuje obnovenie ako požiadavku pôvodnému serveru v polovici času prenájmu, s opätovným zviazaním na ktorýkoľvek server v siedmich osminách, ak prvý pokus zostane bez odpovede. Ani jeden krok nevyžaduje, aby klient získal inú adresu, a spolupracujúci server zvyčajne predĺži existujúce zviazanie. Skutočná zmena adresy zvyčajne prichádza inou cestou: server odmietne obnovenie, klient stratil svoj stav a začal znova, alebo sieť presunula zariadenie do iného segmentu.

Verejná strana spojenia sa môže zmeniť bez akejkoľvek lokálnej zmeny. Za prekladom na úrovni operátora môže byť adresa, ktorú vidí partner VPN, prerozdelená nezávisle od toho, čo urobil lokálny prenájom, a toto prerozdelenie vyzerá zvnútra klienta rovnako ako lokálna sieťová porucha. Porovnanie lokálne hlásenej adresy s pozorovaním na strane partnera je jediný spôsob, ako ich oddeliť.

Keď sa klient nedokáže prispôsobiť

Klient, ktorý zviazal svoj transport so starou adresou, uložil do vyrovnávacej pamäte zastaranú trasu k partnerovi alebo si uložil identitu rozhrania, môže ďalej skúšať cestu, ktorá už neexistuje. To je porucha prispôsobenia a prejavuje sa ako opakované prenosy na adresu, ktorú hostiteľ už nedokáže dosiahnuť. Niektorí klienti to riešia konštrukčne: WireGuard napríklad aktualizuje koncový bod partnera, keď dorazí správne overený paket z nového zdroja.

Ručný reštart, ktorý obnoví službu, je stopa k tomu, kde prispôsobenie zlyhalo, nie dôkaz, že prenájmy a tunely sú nezlučiteľné. Počas testovania ponechajte blokovaciu politiku zapnutú, inak sa samotný test stane výpadkom s inou príčinou. Zaznamenajte, či sa klient zotavil sám, ako dlho to trvalo a na ktorú adresu to skúsil znova; táto postupnosť vám povie viac než dôvod odpojenia zobrazený v rozhraní.

Než niečo obviníte, udalosť zopakujte

Reprodukujte podmienku namiesto čakania na plán: uvoľnite a obnovte prenájom alebo vynúťte zodpovedajúcu riadenú udalosť a sledujte, či tunel prežije. V riadenej sieti zlaďte akúkoľvek zmenu adresy so správcom siete, pretože ľubovoľné statické priradenie sa môže zraziť so zariadením, ktoré tú adresu už má.

Po podporovanej oprave zopakujte tú istú udalosť a potom otestujte aplikáciu a preklad mena, pretože tunel, ktorý sa znova pripojí, ale rozbije DNS, prejde slabším testom než ten, na ktorom záleží. Nahláste konkrétnu pozorovanú zmenu s jej časovou pečiatkou, namiesto toho, aby ste plánovaný prenájom označili za príčinu. Rozdiel medzi týmito dvoma správami je v tom, či ďalší človek dokáže poruchu reprodukovať, alebo len fámu.