VPN kopplar från med samma intervall? Stäm av timern
Ett avbrott med fast intervall är ett fingeravtryck. Jämför tunnelns nyckelförnyelse, NAT:s inaktivitetstimer, DHCP-leasen och kontogränsen innan du ändrar något.
En tunnel som dör var femtonde minut, eller varje timme på samma minut, säger att någon timer har löpt ut, inte att nätet är instabilt. Det användbara draget är att skriva ner intervallet och jämföra det med de fyra timers som skapar mönstret. Att ändra tidsgränser före den jämförelsen flyttar oftast felet utan att förklara det, vilket gör nästa förekomst svårare att läsa än den första. Mätningen tar tio minuter och ersätter en vecka av gissningar.
Gör intervallet till en siffra
Samla fem eller sex förekomster och beräkna gapet mellan dem, inte gapet från dagens början. Ett avbrott klockan 09:12, 10:12 och 11:12 är en timgräns; ett avbrott klockan 09:12, 09:27 och 09:42 är femton minuter från den senaste lyckade anslutningen. Avrunda resultatet till den mest sannolika timern, inte till närmaste minut.
Anteckna två tidpunkter per händelse: när trafiken senast rörde sig och när klienten rapporterade frånkopplingen. De skiljer sig när en tunnel dör tyst och klienten bara märker det vid nästa sändning, och det är den skillnaden som skiljer en inaktivitetstimeout från ett hårt fel. En klient som märker det sent blåser upp det inaktivitetsfönster du mäter.
Notera om återanslutningen är automatisk. En klient som återansluter inom sekunder håller intervallet synligt i loggen och utanför användarrapporten, och därför beskrivs dessa fel ofta som tillfälliga snarare än periodiska. Den döljer också händelsen för personen som använder laptopen.
Fyra timers som ser likadana ut
Nästan varje återkommande tunnelfall kommer från en av dessa: en protokollnyckelförnyelse, ett utgånget inaktivt mappning, en DHCP- eller gränssnittshändelse eller en kontopolitik. De skiljer sig i om trafik pågick och i vad loggen säger vid gränsen.
Signaturerna nedan är värda att lära sig, eftersom de låter dig avvisa tre förklaringar från en enda loggrada:
| 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 |
Första raden är en säkerhetsmekanism som gör sitt jobb, och den andra är en mellanliggande enhet som glömmer tillstånd. Att blanda ihop dem leder antingen till att försvaga förnyelsen eller till att jaga en brandväggsregel som aldrig var inblandad.
Upptagen kontra inaktiv säger vilken halva
Gör en kontrollerad jämförelse med kontinuerlig trafik, till exempel en lång ström till en värd inuti tunneln, och se om intervallet ändras. Om avbrottet försvinner medan data flödar är timern inaktivitetsbaserad.
Om det överlever kontinuerlig trafik hör orsaken till förnyelse, lease eller policy. Det enda testet tar bort hälften av kandidaterna på ungefär en timmes observation, och det kostar inget annat än uppmärksamhet.
Håll åtkomstnätet oförändrat under testet. Att växla mellan Wi-Fi och Ethernet mitt i jämförelsen inför precis den gränssnittshändelse du försöker skilja från en timer.
Stäm av loggraden mot gränsen
Läs klient- och serverloggarna kring den registrerade tidpunkten, inte hela filen. En förnyelse visar förhandling; ett inaktivitetsutgång visar ingenting förrän nästa paket; en leaseändring visar adressarbete; en policygräns visar vanligtvis en ren administrativ frånkoppling.
Dessa kommandon hämtar det relevanta fönstret från varje källa:
grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg showOm de tre källorna stämmer överens om tidsstämpeln har du timerns ägare. Om bara klientloggen har något är det förmodligen inte servern som avslutar sessionen.
Reparera steget, inte ikonen
Varje ägare har en stödd reparation. Ett förnyelsefel kräver kompatibla förslag i båda ändar. En inaktivitetsutgång kräver en keepalive eller en kortare inaktivitetsförväntan, inom det banan tillåter. En leasehändelse kräver att gränssnitts- eller ströminställningar rättas till. En kontogräns är ett policybeslut, inte en bugg.
Att stänga av förnyelse eller autentisering för att hålla ikonen grön byter ett synligt avbrott mot en osynlig svaghet, och det lämnar dig utan möjlighet att säga när tunneln senast förhandlade fram nya nycklar. Testa den ursprungliga varaktigheten igen efteråt och spara tidsstämplarna, så att nästa händelse kan jämföras med den här i stället för att börja om.