VPN kobler fra med samme intervall? Innstill timeren
Et fall med fast intervall er et fingeravtrykk. Sammenlign tunnelens nøkkelfornyelse, NAT-inaktivitetstimeren, DHCP-leasen og kontogrensen før du endrer noe.
En tunnel som dør hvert femtende minutt, eller hver time på samme minutt, forteller deg at en eller annen timer er utløpt, ikke at nettverket er ustabilt. Det nyttige trekket er å skrive ned intervallet og sammenligne det med de fire timeme som lager dette mønsteret. Å endre tidsavbruddene før den sammenligningen flytter vanligvis feilen uten å forklare den, noe som gjør neste forekomst vanskeligere å lese enn den første. Målingen tar ti minutter og erstatter en uke med gjetting.
Gjør intervallet om til et tall
Samle fem eller seks forekomster og beregn avstanden mellom dem, ikke avstanden fra dagens start. Et fall klokken 09:12, 10:12 og 11:12 er en timesgrense; et fall klokken 09:12, 09:27 og 09:42 er femten minutter fra den siste vellykkede tilkoblingen. Rund av resultatet til den nærmeste sannsynlige timeren i stedet for til nærmeste minutt.
Noter to tidspunkter per hendelse: når trafikken sist beveget seg, og når klienten rapporterte frakoblingen. De er forskjellige når en tunnel dør stille og klienten først oppdager det ved neste sending, og forskjellen er det som skiller en inaktivitetstidsavbrudd fra en hard feil. En klient som oppdager det sent, blåser opp inaktivitetsvinduet du måler.
Legg merke til om gjenoppkoblingen er automatisk. En klient som kobler til igjen innen sekunder, holder intervallet synlig i loggen og utenfor brukerrapporten, og derfor beskrives disse feilene ofte som av og til snarere enn periodiske. Den skjuler også hendelsen for personen som bruker laptopen.
Fire timere som ser like ut
Nesten hvert gjentatte tunnelfall kommer fra en av disse: en protokollnøkkelfornyelse, et utløpt inaktivt mapping, en DHCP- eller grensesnitthendelse eller en kontopolitikk. De skiller seg i om trafikk var i gang og i hva loggen sier ved grensen.
Signaturene nedenfor er verdt å lære, fordi de lar deg avvise tre forklaringer fra én enkelt logglinje:
| Timer | Typical trigger | What the log shows at the boundary |
|---|---|---|
| Protocol rekey | Traffic present, fixed interval | Negotiation lines, sometimes a failure |
| NAT or firewall idle | No traffic for minutes | Silence, then a timeout on send |
| DHCP lease or link change | Half the lease, or a radio event | Address or interface churn |
| Account session limit | Wall-clock hours since login | Clean disconnect, server-side reason |
Den første raden er en sikkerhetsmekanisme som gjør jobben sin, og den andre er en mellomliggende enhet som glemmer tilstand. Å forveksle dem fører enten til å svekke fornyelsen eller til å jage en brannmurregel som aldri var involvert.
Opptatt kontra inaktiv forteller deg hvilken halvdel
Kjør en kontrollert sammenligning med vedvarende trafikk, for eksempel en lang strøm til en vert inne i tunnelen, og se om intervallet endres. Hvis fallet forsvinner mens data flyter, er timeren inaktivitetsbasert.
Hvis det overlever vedvarende trafikk, hører utløseren til fornyelse, lease eller policy. Den ene testen fjerner halvparten av kandidatene på omtrent en time med observasjon, og den koster ingenting annet enn oppmerksomhet.
Hold aksessnettet uendret under testen. Å bytte mellom Wi-Fi og Ethernet midt i sammenligningen introduserer nettopp den grensesnitthendelsen du prøver å skille fra en timer.
Tilpass logglinjen til grensen
Les klient- og serverloggene rundt det registrerte tidspunktet, ikke hele filen. En fornyelse viser forhandling; et inaktivitetsutløp viser ingenting før neste pakke; en leaseendring viser adressearbeid; en policygrense viser vanligvis en ren administrativ frakobling.
Disse kommandoene henter det relevante vinduet fra hver kilde:
grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg showHvis de tre kildene er enige om tidsstempelet, har du eieren av timeren. Hvis bare klientloggen har noe, er det sannsynligvis ikke serveren som avslutter økten.
Reparer fasen, ikke ikonet
Hver eier har én støttet reparasjon. En fornyelsesfeil krever kompatible forslag i begge ender. Et inaktivitetsutløp krever en keepalive eller en kortere inaktivitetsforventning, innenfor det banen tillater. En leasehendelse krever at grensesnitt- eller strøminnstillinger rettes opp. En kontogrense er en policybeslutning, ikke en feil.
Å slå av fornyelse eller autentisering for å holde ikonet grønt bytter et synlig fall mot en usynlig svakhet, og det etterlater deg uten mulighet til å si når tunnelen sist forhandlet friske nøkler. Test den opprinnelige varigheten på nytt etterpå og ta vare på tidsstemplene, slik at neste hendelse kan sammenlignes med denne i stedet for å begynne på nytt.