VPN falder efter en DHCP-fornyelse? Sammenlign adresserne

Leasefornyelse og VPN-svigt optræder ofte nok sammen i logfiler til, at folk konkluderer, at det ene forårsager det andet. Tidsmæssig sammenfald er reel; kausaliteten er det normalt ikke. En fornyelse er en unicast-anmodning til serveren, der udstedte leasen, om at fortsætte med den samme binding, og serveren kan forlænge den, uden at klienten ændrer en eneste adresse. At gennemgå klientens egne værdier omkring hændelsen adskiller en lease, der blev fornyet i stilhed, fra et netværk, der reelt ændrede sig under en kørende tunnel.

Start med den klient, der faldt

Åbn først klientens forbindelseslog og notér tidspunktet for afbrydelsen til sekundet. Åbn derefter operativsystemets netværkslog for samme minut og læs i rækkefølge, hvad grænsefladen gjorde. Denne rækkefølge er hele undersøgelsen: en DHCP-hændelse før afbrydelsen, en afbrydelse før DHCP-hændelsen og to hændelser uden noget imellem er tre forskellige fund. En loglinje, der blot nævner leasen, mens tunnelen allerede genoprettede forbindelsen, er dekoration, ikke bevis.

Skriv tidslinjen ned undervejs i stedet for at holde den i hovedet. Tidsstempler fra forskellige værktøjer stemmer sjældent perfekt overens, og selve afvigelsen er undertiden forklaringen.

Sammenlign de fire værdier omkring hændelsen

Fire værdier beskriver den lokale side af en forbindelse godt nok til at fange en reel ændring: grænsefladens adresse, standardgatewayen, resolverlisten og grænsefladens driftstilstand. Tag dem inden for et minut efter afbrydelsen, og sammenlign med en optagelse fra mens tunnelen var sund.

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 uændret adresse med uændret gateway og en ændret resolverliste peger på navneopløsning frem for routing, og tunnelen kan have overlevet, mens programmer holdt op med at finde værter. En ændret gateway betyder, at vejen ud af det lokale netværk flyttede sig, hvilket er nok til at ugyldiggøre en rute, der pegede på den forrige. Hvis alle fire værdier matcher den sunde optagelse, er leasen ikke din årsag, og klientens egen genopkoblingslogik bliver emnet. Tag sammenligningen, mens fejlen er synlig, fordi en sund optagelse taget efter en genstart har en anden adressehistorik og ikke vil matche.

Hvad en fornyelse kan og ikke kan ændre

RFC 2131 beskriver fornyelse som en anmodning til den oprindelige server på halvdelen af leasetiden, med genbinding til enhver server på syv ottendedele, hvis det første forsøg forbliver ubesvaret. Ingen af trinene kræver, at klienten får en anden adresse, og en samarbejdsvillig server forlænger normalt den eksisterende binding. En reel adresseændring kommer normalt ad en anden vej: en server, der afviser fornyelsen, en klient, der mistede sin tilstand og startede forfra, eller et netværk, der flyttede enheden til et andet segment.

Forbindelsens offentlige side kan ændre sig uden nogen lokal ændring overhovedet. Bag carrier-grade-oversættelse kan den adresse, VPN-partneren ser, blive tildelt på ny uafhængigt af alt, hvad den lokale lease gjorde, og den omtildeling ser inde fra klienten identisk ud med en lokal netværksfejl. At sammenligne en lokalt rapporteret adresse med en observation fra partnerens side er den eneste måde at skelne dem.

Når klienten ikke formår at tilpasse sig

En klient, der bandt sin transport til den gamle adresse, cachelagrede en forældet rute til partneren eller gemte en grænsefladeidentitet, kan blive ved med at forsøge en vej, der ikke findes længere. Det er en tilpasningsfejl, og den ses som gentagne videresendelser mod en adresse, som værten ikke længere kan nå. Nogle klienter håndterer det ved design: WireGuard opdaterer for eksempel en partners endepunkt, når en korrekt autentificeret pakke ankommer fra en ny kilde.

En manuel genstart, der genopretter tjenesten, er et fingerpeg om, hvor tilpasningen fejlede, ikke et bevis for, at leases og tunnels er uforenelige. Hold blokeringspolitikken på plads under testen, ellers bliver testen selv et udfald med en anden årsag. Notér, om klienten kom sig af sig selv, hvor lang tid det tog, og hvilken adresse den forsøgte igen; den sekvens fortæller dig mere end afbrydelsesårsagen, der vises i grænsefladen.

Gentag hændelsen, før du bebrejder den

Genskab betingelsen i stedet for at vente på tidsplanen: frigiv og forny leasen, eller fremtving den tilsvarende kontrollerede hændelse, og se, om tunnelen overlever. På et administreret netværk skal du koordinere enhver adresseændring med netværksejeren, fordi en vilkårlig statisk tildeling kan kollidere med en enhed, der allerede har den adresse.

Efter en understøttet rettelse gentages den samme hændelse, og derefter testes et program og et navneopslag, fordi en tunnel, der genopretter forbindelsen, men ødelægger DNS, består en svagere test end den, der betyder noget. Rapporter den konkrete ændring, du observerede, med dens tidsstempel, i stedet for at udpege den planlagte lease som årsag. Forskellen på de to rapporter er, om den næste person kan genskabe fejlen eller kun rygterne.