Valt de VPN weg na een DHCP-vernieuwing? Vergelijk de adressen

Leasevernieuwing en VPN-uitval verschijnen vaak genoeg samen in logs dat mensen concluderen dat het ene het andere veroorzaakt. De timing klopt; de causaliteit meestal niet. Een vernieuwing is een unicast-verzoek aan de server die de lease uitgaf, om dezelfde binding te blijven gebruiken, en de server kan die verlengen zonder dat de client één adres wijzigt. De eigen waarden van de client rond de gebeurtenis nalopen scheidt een stil vernieuwde lease van een netwerk dat werkelijk veranderde onder een draaiende tunnel.

Begin bij de client die wegviel

Open eerst het verbindingslog van de client en noteer het tijdstip van de onderbreking tot op de seconde. Open daarna het netwerklog van het besturingssysteem voor dezelfde minuut en lees op volgorde wat de interface deed. Deze volgorde is het hele onderzoek: een DHCP-gebeurtenis vóór de verbreking, een verbreking vóór de DHCP-gebeurtenis en twee gebeurtenissen zonder iets ertussen zijn drie verschillende bevindingen. Een logregel die alleen de lease noemt terwijl de tunnel al opnieuw verbond, is decoratie, geen bewijs.

Schrijf de tijdlijn gaandeweg op in plaats van die in het hoofd te houden. Tijdstempels van verschillende hulpmiddelen komen zelden perfect overeen, en de afwijking zelf is soms de verklaring.

Vergelijk de vier waarden rond de gebeurtenis

Vier waarden beschrijven de lokale kant van een verbinding goed genoeg om een echte wijziging te vangen: het adres van de interface, de standaardgateway, de resolverlijst en de operationele status van de interface. Leg ze binnen een minuut na de onderbreking vast en vergelijk ze met een opname die is gemaakt toen de tunnel gezond was.

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

Een ongewijzigd adres met een ongewijzigde gateway en een gewijzigde resolverlijst wijst op naamresolutie in plaats van routing, en de tunnel kan hebben overleefd terwijl toepassingen hosts niet meer vonden. Een gewijzigde gateway betekent dat de route uit het lokale netwerk is verschoven, en dat is genoeg om een route ongeldig te maken die naar de vorige wees. Als alle vier waarden overeenkomen met de gezonde opname, is de lease niet uw oorzaak en wordt de eigen herverbindingslogica van de client het onderwerp. Maak de vergelijking terwijl de fout zichtbaar is, want een gezonde opname na een herstart heeft een andere adressengeschiedenis en zal niet overeenkomen.

Wat een vernieuwing wel en niet kan veranderen

RFC 2131 beschrijft vernieuwing als een verzoek aan de oorspronkelijke server op de helft van de leasetijd, met herbinding aan elke server op zeven achtsten als de eerste poging onbeantwoord blijft. Geen van beide stappen vereist dat de client een ander adres krijgt, en een coöperatieve server verlengt gewoonlijk de bestaande binding. Een echte adreswijziging komt meestal via een andere weg: een server weigert de vernieuwing, een client verloor zijn status en begon opnieuw, of een netwerk verplaatste het apparaat naar een ander segment.

De openbare kant van de verbinding kan veranderen zonder enige lokale wijziging. Achter carrier-grade-vertaling kan het adres dat de VPN-peer ziet opnieuw worden toegewezen, onafhankelijk van alles wat de lokale lease deed, en die toewijzing ziet er van binnenuit de client identiek uit als een lokaal netwerkfout. Een lokaal gerapporteerd adres vergelijken met een waarneming aan de peer-kant is de enige manier om ze te scheiden.

Wanneer de client zich niet aanpast

Een client die zijn transport aan het oude adres bond, een verouderde route naar de peer cachete of een interface-identiteit opsloeg, kan een pad blijven proberen dat niet meer bestaat. Dat is een aanpassingsfout, en die is zichtbaar als herhaalde hertransmissies naar een adres dat de host niet meer kan bereiken. Sommige clients lossen dat ontwerpsgewijs op: WireGuard werkt bijvoorbeeld het eindpunt van een peer bij wanneer een correct geauthenticeerd pakket van een nieuwe bron aankomt.

Een handmatige herstart die de dienst herstelt, is een aanwijzing waar de aanpassing faalde, geen bewijs dat leases en tunnels onverenigbaar zijn. Houd het blokkeringsbeleid aan tijdens het testen, anders wordt de test zelf een storing met een andere oorzaak. Noteer of de client vanzelf herstelde, hoe lang het duurde en welk adres hij opnieuw probeerde; die volgorde zegt u meer dan de verbindingsreden die in de interface wordt getoond.

Herhaal de gebeurtenis voordat u die de schuld geeft

Reproduceer de voorwaarde in plaats van op het schema te wachten: geef de lease vrij en vernieuw hem, of forceer de gelijkwaardige gecontroleerde gebeurtenis, en kijk of de tunnel overleeft. Coördineer op een beheerd netwerk elke adreswijziging met de netwerkeigenaar, want een willekeurige statische toewijzing kan botsen met een apparaat dat dat adres al heeft.

Herhaal na een ondersteunde correctie dezelfde gebeurtenis en test daarna een toepassing en een naamopzoeking, want een tunnel die opnieuw verbindt maar DNS breekt, slaagt voor een zwakkere test dan degene die ertoe doet. Rapporteer de specifieke wijziging die u zag, met het tijdstempel, in plaats van de geplande lease als oorzaak aan te wijzen. Het verschil tussen die twee rapporten is of de volgende persoon de fout kan reproduceren of alleen het gerucht.