VPN koplar frå med same intervall? Innstill timeren
Eit fall med fast intervall er eit fingeravtrykk. Samanlikn nøkkelfornyinga til tunnelen, NAT-inaktivitetstimeren, DHCP-leiga og kontogrensa før du endrar noko.
Ein tunnel som døyr kvart femtande minutt, eller kvar time på same minutt, fortel deg at ein eller annan timer er gått ut, ikkje at nettet er ustabilt. Det nyttige trekket er å skrive ned intervallet og samanlikne det med dei fire timerane som lagar dette mønsteret. Å endre tidsavbrota før den samanlikninga flyttar vanlegvis feilen utan å forklare han, noko som gjer neste førekomst vanskelegare å lese enn den første. Målinga tek ti minutt og erstattar ei veke med gjetting.
Gjer intervallet om til eit tal
Samle fem eller seks førekomstar og rekn ut avstanden mellom dei, ikkje avstanden frå dagens start. Eit fall klokka 09:12, 10:12 og 11:12 er ei timesgrense; eit fall klokka 09:12, 09:27 og 09:42 er femten minutt frå den siste vellukka tilkoplinga. Rund av resultatet til den næraste sannsynlege timeren i staden for til næraste minutt.
Noter to tidspunkt per hending: når trafikken sist rørte seg, og når klienten rapporterte fråkoplinga. Dei er ulike når ein tunnel døyr stille og klienten først oppdagar det ved neste sending, og skilnaden er det som skil eit inaktivitetstidsavbrot frå ein hard feil. Ein klient som oppdagar det seint, blæs opp inaktivitetsvindauget du måler.
Legg merke til om attoppkoplinga er automatisk. Ein klient som koplar til att innan sekund, held intervallet synleg i loggen og utanfor brukarrapporten, og difor blir desse feila ofte skildra som av og til snarare enn periodiske. Han gøymer òg hendinga for personen som brukar laptopen.
Fire timerar som ser like ut
Nesten kvart gjentekne tunnelfall kjem frå ein av desse: ei protokollnøkkel-fornying, eit utgått inaktivt mapping, ei DHCP- eller grensesnitthending eller ein kontopolitikk. Dei skil seg i om trafikk var i gang og i kva loggen seier ved grensa.
Signaturen nedanfor er verdt å lære, fordi dei lèt deg avvise tre forklaringar frå éi 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 rada er ein tryggleiksmekanisme som gjer jobben sin, og den andre er eit mellomliggjande apparat som gløymer tilstand. Å forveksle dei fører anten til å svekke fornyinga eller til å jage ein brannmurregel som aldri var involvert.
Oppteken kontra inaktiv fortel deg kva halvdel
Køyr ei kontrollert samanlikning med vedvarande trafikk, til dømes ein lang straum til ein vert inne i tunnelen, og sjå om intervallet endrar seg. Viss fallet forsvinn medan data flyt, er timeren inaktivitetsbasert.
Viss det overlever vedvarande trafikk, høyrer utløysaren til fornying, leige eller policy. Den eine testen fjernar halvparten av kandidatane på omtrent ein time med observasjon, og han kostar ingenting anna enn merksemd.
Hald aksessnettet uendra under testen. Å byte mellom Wi-Fi og Ethernet midt i samanlikninga introduserer nettopp den grensesnitthendinga du prøver å skilje frå ein timer.
Tilpass logglinja til grensa
Les klient- og serverloggane rundt det registrerte tidspunktet, ikkje heile fila. Ei fornying viser forhandling; eit inaktivitetsutløp viser ingenting før neste pakke; ei leigeendring viser adressearbeid; ei policygrense viser vanlegvis ei rein administrativ fråkopling.
Desse kommandoane hentar det relevante vindauget frå kvar kjelde:
grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg showViss dei tre kjeldene er samde om tidsstempelet, har du eigaren av timeren. Viss berre klientloggen har noko, er det sannsynlegvis ikkje serveren som avsluttar økta.
Reparer fasen, ikkje ikonet
Kvar eigar har éin støtta reparasjon. Ein fornyingsfeil krev kompatible forslag i begge endar. Eit inaktivitetsutløp krev ein keepalive eller ei kortare inaktivitetsforventning, innanfor det banen tillèt. Ei leigehending krev at grensesnitt- eller strauminustillingar blir retta opp. Ei kontogrense er eit policyvedtak, ikkje ein feil.
Å slå av fornying eller autentisering for å halde ikonet grønt byter eit synleg fall mot ei usynleg svakheit, og det lèt deg ikkje seie når tunnelen sist forhandla friske nøklar. Test den opphavlege varigheita på nytt etterpå og ta vare på tidsstempla, slik at neste hending kan samanliknast med denne i staden for å byrje på nytt.