Tappar VPN efter en DHCP-förnyelse? Jämför adresserna

Leaseförnyelse och VPN-fel dyker ofta nog upp tillsammans i loggar för att folk ska dra slutsatsen att det ena orsakar det andra. Tidssambandet är verkligt; kausaliteten oftast inte. En förnyelse är en unicast-begäran till servern som utfärdade leasen, om att fortsätta använda samma bindning, och servern kan förlänga den utan att klienten ändrar en enda adress. Att gå igenom klientens egna värden kring händelsen skiljer en tyst förnyad lease från ett nätverk som faktiskt förändrades under en pågående tunnel.

Börja med klienten som tappade

Öppna först klientens anslutningslogg och notera tidpunkten för avbrottet till sekunden. Öppna sedan operativsystemets nätverkslogg för samma minut och läs i ordning vad gränssnittet gjorde. Den ordningen är hela utredningen: en DHCP-händelse före frånkopplingen, en frånkoppling före DHCP-händelsen och två händelser utan något emellan är tre olika fynd. En loggrad som bara nämner leasen medan tunneln redan återanslöt är dekoration, inte bevis.

Skriv ned tidslinjen efter hand i stället för att hålla den i minnet. Tidsstämplar från olika verktyg stämmer sällan exakt, och själva avvikelsen är ibland förklaringen.

Jämför de fyra värdena kring händelsen

Fyra värden beskriver den lokala sidan av en anslutning tillräckligt väl för att fånga en verklig förändring: gränssnittets adress, standardgatewayen, resolverlistan och gränssnittets driftstatus. Fånga dem inom en minut efter avbrottet och jämför med en mätning som gjordes medan tunneln 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 oförändrad adress med oförändrad gateway och en ändrad resolverlista pekar på namnmatchning i stället för routing, och tunneln kan ha överlevt medan applikationer slutade hitta värdar. En ändrad gateway betyder att vägen ut ur det lokala nätet flyttades, vilket räcker för att ogiltigförklara en rutt som pekade på den föregående. Om alla fyra värden stämmer med den friska mätningen är leasen inte din orsak, och klientens egen återanslutningslogik blir ämnet. Gör jämförelsen medan felet syns, eftersom en frisk mätning efter omstart har en annan adresshistorik och inte kommer att stämma.

Vad en förnyelse kan och inte kan ändra

RFC 2131 beskriver förnyelse som en begäran till den ursprungliga servern vid halva leasetiden, med ombindning till vilken server som helst vid sju åttondelar om det första försöket lämnas obesvarat. Inget av stegen kräver att klienten får en annan adress, och en samarbetsvillig server förlänger vanligen den befintliga bindningen. En verklig adressändring kommer oftast via en annan väg: en server avvisar förnyelsen, en klient förlorade sitt tillstånd och började om, eller ett nätverk flyttade enheten till ett annat segment.

Anslutningens offentliga sida kan ändras utan någon lokal ändring alls. Bakom operatörsnivåöversättning kan adressen som VPN-peeren ser tilldelas om oberoende av allt den lokala leasen gjorde, och den omtilldelningen ser identisk ut med ett lokalt nätverksfel inifrån klienten. Att jämföra en lokalt rapporterad adress med en observation från peersidan är det enda sättet att skilja dem.

När klienten inte lyckas anpassa sig

En klient som band sin transport till den gamla adressen, cachelagrade en inaktuell rutt till peeren eller sparade en gränssnittsidentitet kan fortsätta att försöka en väg som inte längre finns. Det är ett anpassningsfel, och det syns som upprepade omsändningar mot en adress som värden inte längre kan nå. Vissa klienter hanterar det enligt design: WireGuard uppdaterar till exempel en peers slutpunkt när ett korrekt autentiserat paket anländer från en ny källa.

En manuell omstart som återställer tjänsten är en ledtråd till var anpassningen misslyckades, inte ett bevis på att leases och tunnlar är oförenliga. Håll blockeringspolicyn på plats under testet, annars blir testet självt ett avbrott med en annan orsak. Anteckna om klienten återhämtade sig själv, hur lång tid det tog och vilken adress den försökte igen; den sekvensen säger mer än frånkopplingsorsaken som visas i gränssnittet.

Upprepa händelsen innan du skyller på den

Reproducera villkoret i stället för att vänta på schemat: släpp och förnya leasen, eller framtvinga den likvärdiga kontrollerade händelsen, och se om tunneln överlever. I ett hanterat nätverk, samordna varje adressändring med nätverksägaren, eftersom en godtycklig statisk tilldelning kan kollidera med en enhet som redan har den adressen.

Efter en stödd rättelse, upprepa samma händelse och testa sedan en applikation och en namnsökning, eftersom en tunnel som återansluter men bryter DNS klarar ett svagare test än det som betyder något. Rapportera den specifika ändring du observerade, med dess tidsstämpel, i stället för att utpeka den schemalagda leasen som orsak. Skillnaden mellan de två rapporterna är om nästa person kan reproducera felet eller bara ryktet.