Faller VPN etter en DHCP-fornyelse? Sammenlign adressene

Leasefornyelse og VPN-svikt dukker ofte nok opp sammen i logger til at folk konkluderer med at det ene forårsaker det andre. Tidssammenfallen er reell; årsakssammenhengen vanligvis ikke. En fornyelse er en unicast-forespørsel til serveren som utstedte leasen, om å fortsette med samme binding, og serveren kan forlenge den uten at klienten endrer én eneste adresse. Å gå gjennom klientens egne verdier rundt hendelsen skiller en lease som ble fornyet i stillhet fra et nettverk som faktisk endret seg under en kjørende tunnel.

Start med klienten som falt

Åpne først klientens tilkoblingslogg og noter tidspunktet for fallet til sekundet. Åpne deretter operativsystemets nettverkslogg for samme minutt og les i rekkefølge hva grensesnittet gjorde. Denne rekkefølgen er hele undersøkelsen: en DHCP-hendelse før frakoblingen, en frakobling før DHCP-hendelsen og to hendelser uten noe imellom er tre ulike funn. En logglinje som bare nevner leasen mens tunnelen allerede koblet til på nytt, er dekorasjon, ikke bevis.

Skriv ned tidslinjen underveis i stedet for å holde den i hodet. Tidsstempler fra ulike verktøy stemmer sjelden perfekt overens, og selve avviket er noen ganger forklaringen.

Sammenlign de fire verdiene rundt hendelsen

Fire verdier beskriver den lokale siden av en tilkobling godt nok til å fange en reell endring: grensesnittets adresse, standardgatewayen, resolverlisten og grensesnittets driftstilstand. Ta dem innen ett minutt etter fallet og sammenlign med et opptak tatt mens 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

En uendret adresse med uendret gateway og endret resolverliste peker på navneoppslag fremfor ruting, og tunnelen kan ha overlevd mens applikasjoner sluttet å finne verter. En endret gateway betyr at veien ut av det lokale nettverket flyttet seg, noe som er nok til å ugyldiggjøre en rute som pekte på den forrige. Hvis alle fire verdier stemmer med det friske opptaket, er leasen ikke din årsak, og klientens egen gjenoppkoblingslogikk blir temaet. Ta sammenligningen mens feilen er synlig, fordi et friskt opptak tatt etter en omstart har en annen adressehistorikk og vil ikke stemme.

Hva en fornyelse kan og ikke kan endre

RFC 2131 beskriver fornyelse som en forespørsel til den opprinnelige serveren ved halvparten av leasetiden, med gjenbinding til enhver server ved sju åttendedeler hvis det første forsøket forblir ubesvart. Ingen av stegene krever at klienten får en annen adresse, og en samarbeidsvillig server forlenger vanligvis den eksisterende bindingen. En reell adresseendring kommer vanligvis via en annen vei: en server avviser fornyelsen, en klient mistet tilstanden sin og startet på nytt, eller et nettverk flyttet enheten til et annet segment.

Den offentlige siden av tilkoblingen kan endre seg uten noen lokal endring i det hele tatt. Bak carrier-grade-oversettelse kan adressen VPN-peeret ser, bli tildelt på nytt uavhengig av alt den lokale leasen gjorde, og den omtildelingen ser identisk ut med en lokal nettverksfeil fra innsiden av klienten. Å sammenligne en lokalt rapportert adresse med en observasjon fra peer-siden er den eneste måten å skille dem.

Når klienten ikke klarer å tilpasse seg

En klient som bandt transporten sin til den gamle adressen, bufret en utdatert rute til peeret eller lagret en grensesnittidentitet, kan fortsette å prøve en vei som ikke finnes lenger. Det er en tilpasningsfeil, og den vises som gjentatte videresendinger mot en adresse verten ikke lenger kan nå. Noen klienter håndterer det ved design: WireGuard oppdaterer for eksempel endepunktet til en peer når en korrekt autentisert pakke ankommer fra en ny kilde.

En manuell omstart som gjenoppretter tjenesten, er et hint om hvor tilpasningen sviktet, ikke et bevis på at leaser og tunneler er uforenlige. Hold blokkeringspolicyen på plass under testing, ellers blir testen selv et utfall med en annen årsak. Noter om klienten kom seg av seg selv, hvor lang tid det tok og hvilken adresse den prøvde på nytt; den sekvensen forteller deg mer enn frakoblingsårsaken som vises i grensesnittet.

Gjenta hendelsen før du gir den skylden

Reproduser betingelsen i stedet for å vente på tidsplanen: slipp og forny leasen, eller fremtving den tilsvarende kontrollerte hendelsen, og se om tunnelen overlever. På et administrert nettverk, koordiner enhver adresseendring med nettverkseieren, fordi en vilkårlig statisk tildeling kan kollidere med en enhet som allerede har den adressen.

Etter en støttet rettelse, gjenta den samme hendelsen og test deretter en applikasjon og et navneoppslag, fordi en tunnel som kobler til på nytt men ødelegger DNS, består en svakere test enn den som betyr noe. Rapporter den konkrete endringen du observerte, med tidsstempelet, i stedet for å utpeke den planlagte leasen som årsak. Forskjellen mellom de to rapportene er om neste person kan reprodusere feilen eller bare ryktet.