VPN afbrydes med samme interval? Afstem timeren
Et drop med fast interval er et fingeraftryk. Sammenlign tunnelens nøglefornyelse, NAT-inaktivitetstimeren, DHCP-leasen og kontolimiten, før du ændrer noget.
En tunnel, der dør hvert femtende minut, eller hver time på samme minut, fortæller dig, at en eller anden timer er udløbet, og ikke at netværket er ustabilt. Det nyttige træk er at skrive intervallet ned og sammenligne det med de fire timere, der skaber dette mønster. At ændre timeouts før den sammenligning flytter som regel fejlen uden at forklare den, hvilket gør den næste forekomst sværere at læse end den første. Målingen tager ti minutter og erstatter en uges gætteri.
Omsæt intervallet til et tal
Indsaml fem eller seks forekomster og beregn afstanden mellem dem, ikke afstanden fra dagens begyndelse. Et drop klokken 09:12, 10:12 og 11:12 er en timesgrænse; et drop klokken 09:12, 09:27 og 09:42 er femten minutter fra den sidste vellykkede forbindelse. Afrund resultatet til den nærmeste sandsynlige timer i stedet for til det nærmeste minut.
Notér to tidspunkter pr. hændelse: hvornår trafikken sidst bevægede sig, og hvornår klienten rapporterede afbrydelsen. De er forskellige, når en tunnel dør lydløst, og klienten først opdager det ved næste send, og forskellen er det, der adskiller en inaktivitetstimeout fra en hård fejl. En klient, der opdager det sent, blæser det inaktivitetsvindue op, du måler.
Bemærk, om genopkoblingen er automatisk. En klient, der genopkobler inden for sekunder, holder intervallet synligt i loggen og ude af brugerrapporten, og derfor beskrives disse fejl ofte som lejlighedsvise frem for periodiske. Den skjuler også hændelsen for den person, der bruger laptop'en.
Fire timere, der ligner hinanden
Næsten hvert gentaget tunnelnedbrud kommer fra en af disse: en protokolnøglefornyelse, et inaktivt mapping-udløb, en DHCP- eller interfacehændelse eller en kontopolitik. De adskiller sig i, om der var trafik, og i hvad loggen siger ved grænsen.
Signaturerne nedenfor er værd at lære, fordi de lader dig afvise tre forklaringer ud fra én loglinje:
| 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 række er en sikkerhedsmekanisme, der gør sit arbejde, og den anden er en mellemboks, der glemmer tilstand. At forveksle dem fører enten til at svække fornyelsen eller til at jage en firewallregel, der aldrig var involveret.
Travl versus inaktiv fortæller dig hvilken halvdel
Kør en kontrolleret sammenligning med vedvarende trafik, for eksempel en lang stream til en vært inde i tunnelen, og se, om intervallet ændrer sig. Hvis droppet forsvinder, mens data flyder, er timeren inaktivitetsbaseret.
Hvis det overlever vedvarende trafik, hører udløseren til fornyelse, lease eller politik. Den ene test fjerner halvdelen af kandidaterne på omkring en times observation, og den koster intet andet end opmærksomhed.
Hold adgangsnetværket uændret under testen. At skifte mellem Wi-Fi og Ethernet midt i sammenligningen indfører netop den interfacehændelse, du prøver at skelne fra en timer.
Afstem loglinjen med grænsen
Læs klient- og serverloggen omkring det registrerede tidspunkt, ikke hele filen. En fornyelse viser forhandling; et inaktivitetsudløb viser intet indtil næste pakke; en leaseændring viser adressearbejde; en politisk grænse viser som regel en ren administrativ afbrydelse.
Disse kommandoer trækker det relevante vindue 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 kilder er enige om tidsstemplet, har du timerens ejer. Hvis kun klientloggen har noget, er det sandsynligvis ikke serveren, der afslutter sessionen.
Ret fasen, ikke ikonet
Hver ejer har én understøttet reparation. En fornyelsesfejl kræver kompatible forslag i begge ender. Et inaktivitetsudløb kræver en keepalive eller en kortere inaktivitetsforventning inden for det, stien tillader. En leasehændelse kræver, at interface- eller strømindstillinger rettes. En kontolimit er en politisk beslutning, ikke en fejl.
At slå fornyelse eller godkendelse fra for at holde ikonet grønt bytter et synligt drop for en usynlig svaghed, og det efterlader dig ude af stand til at sige, hvornår tunnelen sidst forhandlede friske nøgler. Test den oprindelige varighed igen bagefter, og gem tidsstemplerne, så den næste hændelse kan sammenlignes med denne i stedet for at starte forfra.