Fell VPN etter ei DHCP-fornying? Samanlikn adressene

Leasefornying og VPN-svikt dukkar ofte nok opp saman i loggar til at folk konkluderer med at det eine fører til det andre. Tidssamanfallet er reelt; årsakssamanhengen vanlegvis ikkje. Ei fornying er ei unicast-førespurnad til tenaren som gav ut leasa, om å halde fram med same bindinga, og tenaren kan forlengje ho utan at klienten endrar ei einaste adresse. Å gå gjennom klienten sine eigne verdiar rundt hendinga skil ei lease som vart fornya i det stille frå eit nettverk som faktisk endra seg under ein køyrande tunnel.

Start med klienten som fall

Opne først tilkoplingsloggen til klienten og noter tidspunktet for fallet til sekundet. Opne deretter nettverksloggen til operativsystemet for same minutt og les i rekkjefølgje kva grensesnittet gjorde. Denne rekkjefølgja er heile granskinga: ei DHCP-hending før fråkoblinga, ei fråkobling før DHCP-hendinga og to hendingar utan noko imellom er tre ulike funn. Ei logglinje som berre nemner leasa medan tunnelen alt kopla til på nytt, er dekorasjon, ikkje prov.

Skriv ned tidslinja undervegs i staden for å halde ho i hovudet. Tidsstempel frå ulike verktøy stemmer sjeldan perfekt, og sjølve avviket er stundom forklaringa.

Samanlikn dei fire verdiane rundt hendinga

Fire verdiar skildrar den lokale sida av ei tilkopling godt nok til å fange ei reell endring: adressa til grensesnittet, standardgatewayen, resolverlista og driftstilstanden til grensesnittet. Ta dei innan eitt minutt etter fallet og samanlikn med eit opptak teke medan tunnelen var frisk.

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

Ei uendra adresse med uendra gateway og endra resolverliste peikar på namneoppslag framfor ruting, og tunnelen kan ha overlevd medan program slutta å finne vertar. Ein endra gateway tyder på at vegen ut av det lokale nettverket flytta seg, noko som er nok til å gjere ei rute som peika på den førre, ugyldig. Viss alle fire verdiane stemmer med det friske opptaket, er leasa ikkje årsaka di, og eigen gjenoppkoplingslogikk hos klienten blir temaet. Ta samanlikninga medan feilen er synleg, for eit friskt opptak teke etter omstart har ei anna adressehistorikk og vil ikkje stemme.

Kva ei fornying kan og ikkje kan endre

RFC 2131 skildrar fornying som ei førespurnad til den opphavlege tenaren ved halvparten av leasetida, med gjenbinding til kva tenar som helst ved sju åttedelar om det første forsøket blir ståande ubesvart. Ingen av stega krev at klienten får ei anna adresse, og ein samarbeidsvillig tenar forlengjer vanlegvis den eksisterande bindinga. Ei reell adresseendring kjem vanlegvis via ein annan veg: ein tenar avviser fornyinga, ein klient mista tilstanden sin og starta på nytt, eller eit nettverk flytta eininga til eit anna segment.

Den offentlege sida av tilkoplinga kan endre seg utan noka lokal endring i det heile. Bak carrier-grade-omsetjing kan adressa VPN-peeret ser, bli tildelt på nytt uavhengig av alt den lokale leasa gjorde, og den omtildelinga ser identisk ut med ein lokal nettverksfeil frå innsida av klienten. Å samanlikne ei lokalt rapportert adresse med ei observasjon frå peer-sida er den einaste måten å skilje dei.

Når klienten ikkje klarar å tilpasse seg

Ein klient som band transporten sin til den gamle adressa, bufra ei utdatert rute til peeret eller lagra ein grensesnittidentitet, kan halde fram med å prøve ein veg som ikkje finst lenger. Det er ein tilpassingsfeil, og han synest som gjentekne vidaresendingar mot ei adresse verten ikkje lenger kan nå. Nokre klientar handterer det ved design: WireGuard oppdaterer til dømes endepunktet til eit peer når ein korrekt autentisert pakke kjem frå ei ny kjelde.

Ein manuell omstart som gjenopprettar tenesta, er eit hint om kvar tilpassinga svikta, ikkje eit prov på at leaser og tunnelar er uforeinlege. Hald blokkeringspolicyen på plass under testing, elles blir testen sjølv eit utfall med ei anna årsak. Noter om klienten kom seg av seg sjølv, kor lang tid det tok og kva adresse han prøvde på nytt; den sekvensen fortel deg meir enn fråkoblingsårsaka som blir vist i grensesnittet.

Gjenta hendinga før du gir ho skulda

Reproduser vilkåret i staden for å vente på tidsplanen: slepp og forny leasa, eller tving fram den tilsvarande kontrollerte hendinga, og sjå om tunnelen overlever. På eit administrert nettverk, koordiner kvar adresseendring med nettverkseigaren, fordi ei vilkårleg statisk tildeling kan kollidere med ei eining som alt har den adressa.

Etter ei støtta retting, gjenta den same hendinga og test deretter eit program og eit namneoppslag, fordi ein tunnel som koplar til på nytt men øydelegg DNS, står ein svakare test enn den som betyr noko. Rapporter den konkrete endringa du såg, med tidsstempelet, i staden for å peike ut den planlagde leasa som årsak. Skilnaden mellom dei to rapportane er om neste person kan reprodusere feilen eller berre ryktet.