OpenVPN-tapp varje timme: omförhandling eller en riktig återanslutning?

Sextio minuter, eller trettio, eller hundratjugo: ett tapp som landar på ett jämnt intervall är nästan aldrig nätet. OpenVPN förnyar enligt en timer det nyckelmaterial som skyddar datakanalen, och en timer som är kortare än den du antog ser exakt ut som en länk som ständigt misslyckas. Användare rapporterar en bruten anslutning medan loggen rapporterar ett lyckat nyckelutbyte. Guiden nedan skiljer den förnyelsen från en riktig omstart, läser det värde som faktiskt gäller och ändrar det först efter att kostnaden ligger på bordet.

Gör stegen i ordning, eftersom det första avgör om resten av sidan gäller dig alls. Hoppar du framåt lägger du en kväll på att justera en timer för ett fel som inte har något med den att göra.

Skilj en mjuk återställning från en omstart

Loggraden är hela diagnosen. En omförhandling skriver en mjuk återställning och sedan ett nytt nyckelutbyte i samma tunnel: gränssnittet behåller sin adress, rutter läggs inte till igen och etablerade TCP-sessioner överlever oftast med en paus. En riktig omstart sliter sönder sessionen, bygger upp gränssnittet igen, delar kanske ut en annan klientadress och dödar varje långvarig anslutning. Båda händelserna är vanliga; bara en av dem förklarar ett avbrutet samtal.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

Versionsraden spelar roll eftersom loggens formuleringar ändras mellan utgåvor, och ett meddelande du minns från 2.3 kan vara formulerat annorlunda i 2.6. Läs din egen logg i stället för ett forumutdrag från någon annan. Citera den exakta raden när du ber om hjälp, eftersom en parafras tappar detaljen som identifierar händelsen. Om gränssnittets adress är oförändrad under händelsen och sessionslistan överlever, ser du en förnyelse och de återstående avsnitten gäller.

Läs den effektiva timern, inte din fil

reneg-sec är antalet sekunder mellan omförhandlingar av datakanalen, och standardvärdet är 3600. Varje sida bär sitt eget värde, och det mindre av de två är det som faktiskt utlöser förnyelsen. Den enda regeln förklarar de flesta rapporterna: en klientprofil som sätter ett stort tal återställs ändå varje timme så länge servern behåller standardvärdet.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Läs också serverns effektiva konfiguration, inklusive allt den skickar, innan du drar en slutsats av klientfilen. Höj sedan detaljnivån och följ ett intervall från början till slut: nivå 3 visar redan omförhandlingsraderna, och tidsstämplarna säger om händelsen upprepas var 3600 sekund eller följer aktivitet i stället.

Ändra det där det faktiskt skickas

Det kringvandrande botemedlet är en enda rad i klientprofilen, och det är fel plats ungefär halva tiden. Eftersom sidans lägre värde vinner kan en klient som sätter timern till noll ändå omförhandlas av en server som inte ändrades.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Där profiler genereras centralt, redigera mallen och inte den utrullade kopian, annars återställer nästa provisioneringskörning värdet du just tog bort. Verifiera genom att titta på två intervall, inte ett: en enda tyst timme stämmer också med en timer satt till 7200.

Bestäm också vad som händer vid en blandad utrullning. Rullar du ut ändringen till klienter först, finns ett fönster där servern fortfarande utlöser förnyelsen; det är ofarligt men förvirrande om du följer loggarna för bekräftelse. Ändra den sida som har det mindre värdet först och symptomet försvinner vid den punkt du förväntar dig.

Vad du ger upp när du stänger av omförhandlingen

Regelbunden omförhandling begränsar hur länge en enda uppsättning datakanalnycklar skyddar trafiken. Att stänga av timern bryter inte tunneln, och på en hemrouter eller en liten kontorsgateway är den praktiska exponeringen blygsam. Det är ändå ett byte, och bytet är värt att nämna innan du gör det. Det som ändras är hur länge en nyckeluppsättning skyddar en session, inte om tunneln fungerar alls.

Det rimliga fallet för att stänga av det är en återställning som bryter något som inte kan återupptas: ett samtal som faller, en fjärrskrivbordssession som måste återupprättas, en säkerhetskopia som börjar om från början. Om pausen är osynlig för användarna kostar standardvärdet ingenting och bevarar den nyckelrotation du fick.

Föredra att åtgärda orsaken när mönstret tillåter det. En förnyelse som misslyckas halvvägs medan det första handslaget lyckades pekar på vägen och inte på timern: leta efter ett paketstorleksproblem i det större utbytet på kontrollkanalen, en tillståndsbaserad brandvägg som släpper flödet, eller ett förslag som bara lyckas på första försöket. Var och en lämnar ett spår i samma logg som du just läste. Att stänga av timern döljer det beviset.

När intervallet pekar någon annanstans

Två grannar i konfigurationen ger liknande symtom och olika åtgärder. ping-restart startar om tunneln när inget anländer under en konfigurerad period, medan ping-exit tar ner klienten helt. Ett tapp i vila utan någon omförhandling i loggen hör till dessa, eller till en NAT-enhet som lät UDP-mappningen löpa ut enligt sitt eget schema.

Konsumentroutrar, mobila hotspots och operatörsnivå-NAT låter alla inaktiva UDP-sessioner löpa ut utan att säga det till någon. Det felet följer inaktivitet och inte klockan, och det är tecknet: en session som faller efter tio tysta minuter och överlever en timme jämn trafik omförhandlar inte.

Skriv ner tre saker innan du ändrar en fjärde: intervallet du mätte, det effektiva värde du hittade och kommandot som visade det. Om intervallet flyttar sig när timern flyttar sig är mekanismen identifierad och åtgärden är ett beslut om bytet ovan. Om det inte flyttar sig, sätt tillbaka inställningen och fortsätt titta på keepalives, NAT-tillstånd och paketförlust.