VPN spadne po obnovení DHCP? Porovnejte adresy

Obnovení pronájmu a selhání VPN se v protokolech objevují společně dost často na to, aby lidé usoudili, že jedno způsobuje druhé. Časová shoda je skutečná; příčinnost obvykle ne. Obnovení je jednosměrový požadavek serveru, který pronájem vydal, s žádostí pokračovat ve stejném svázání, a server je může prodloužit, aniž by klient změnil jedinou adresu. Projití klientových vlastních hodnot kolem události oddělí pronájem, který se tiše obnovil, od sítě, která se pod běžícím tunelem skutečně změnila.

Začněte u klienta, který vypadl

Nejprve otevřete klientský protokol připojení a zapište čas výpadku na sekundu. Potom otevřete síťový protokol operačního systému pro stejnou minutu a přečtěte si v pořadí, co rozhraní dělalo. Toto pořadí je celé vyšetřování: událost DHCP před odpojením, odpojení před událostí DHCP a dvě události bez ničeho mezi nimi jsou tři různá zjištění. Řádek protokolu, který jen zmiňuje pronájem, zatímco se tunel už znovu připojoval, je dekorace, ne důkaz.

Zapisujte časovou osu průběžně, místo abyste ji drželi v paměti. Časová razítka z různých nástrojů se málokdy kryjí dokonale a sám rozdíl je někdy vysvětlením.

Porovnejte čtyři hodnoty kolem události

Čtyři hodnoty popisují místní stranu spojení dost dobře na to, aby zachytily skutečnou změnu: adresa rozhraní, výchozí brána, seznam resolverů a provozní stav rozhraní. Zachyťte je do minuty po výpadku a porovnejte se záznamem pořízeným, když byl 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

Nezměněná adresa s nezměněnou bránou a změněným seznamem resolverů ukazuje na překlad jmen, nikoli na směrování, a tunel mohl přežít, zatímco aplikace přestaly nacházet hostitele. Změněná brána znamená, že se cesta z místní sítě posunula, což stačí k tomu, aby zneplatnilo trasu, která ukazovala na předchozí. Pokud všechny čtyři hodnoty odpovídají zdravému záznamu, pronájem není vaše příčina a tématem se stává vlastní logika opětovného připojení klienta. Zachyťte srovnání, dokud je závada viditelná, protože zdravý záznam pořízený po restartu má jinou historii adres a nebude odpovídat.

Co obnovení může a co nemůže změnit

RFC 2131 popisuje obnovení jako požadavek původnímu serveru v polovině doby pronájmu, s přesvázáním na jakýkoli server v sedmi osminách, pokud první pokus zůstane bez odpovědi. Ani jeden krok nevyžaduje, aby klient získal jinou adresu, a spolupracující server obvykle prodlouží stávající svázání. Skutečná změna adresy obvykle přichází jinou cestou: server odmítne obnovení, klient ztratil svůj stav a začal znovu, nebo síť přesunula zařízení do jiného segmentu.

Veřejná strana spojení se může změnit bez jakékoli místní změny. Za překladem na úrovni operátora může být adresa, kterou vidí protějšek VPN, přidělena nezávisle na tom, co udělal místní pronájem, a toto přidělení vypadá zevnitř klienta stejně jako místní síťová závada. Porovnání místně hlášené adresy s pozorováním na straně protějšku je jediný způsob, jak je odlišit.

Když se klient nedokáže přizpůsobit

Klient, který svázal svůj transport se starou adresou, uložil do mezipaměti zastaralou trasu k protějšku nebo si uložil identitu rozhraní, může dál zkoušet cestu, která už neexistuje. To je závada přizpůsobení a je vidět jako opakované přenosy na adresu, kterou hostitel už nemůže dosáhnout. Někteří klienti to řeší konstrukčně: WireGuard například aktualizuje koncový bod protějšku, když dorazí správně ověřený paket z nového zdroje.

Ruční restart, který obnoví službu, je stopa k tomu, kde přizpůsobení selhalo, ne důkaz, že pronájmy a tunely jsou neslučitelné. Ponechte blokovací zásadu zapnutou během testování, jinak se samotný test stane výpadkem s jinou příčinou. Zaznamenejte, zda se klient zotavil sám, jak dlouho to trvalo a na kterou adresu to znovu zkoušel; tato posloupnost vám řekne víc než důvod odpojení zobrazený v rozhraní.

Než něco obviníte, událost zopakujte

Reprodukujte podmínku, místo abyste čekali na plán: uvolněte a obnovte pronájem nebo vynuťte odpovídající řízenou událost a sledujte, zda tunel přežije. V řízené síti slaďte jakoukoli změnu adresy se správcem sítě, protože libovolné statické přiřazení se může střetnout se zařízením, které tuto adresu už má.

Po podporované opravě zopakujte stejnou událost a potom otestujte aplikaci a překlad jména, protože tunel, který se znovu připojí, ale rozbije DNS, projde slabším testem než ten, na kterém záleží. Nahlaste konkrétní pozorovanou změnu s jejím časovým razítkem, místo abyste plánovaný pronájem označili za příčinu. Rozdíl mezi těmito dvěma zprávami je v tom, zda další člověk dokáže závadu reprodukovat, nebo jen fámu.