Varför din OpenVPN-klient ligger kvar nere efter en enda tidsgräns

Måndag morgon: tunneln som kom upp i fredags är borta, gränssnittet står kvar i listan och ingenting i journalen säger att någon märkte det. Värden är online, instrumentpanelen är grön och allt den skickade under helgen gick ut genom det fysiska gränssnittet i stället. Här saknas två oberoende beslut: ett om klientprocessen överlever ett tillfälligt fel och ett om något ovanför den startar processen igen efter att den avslutats. Att bara åtgärda ett av dem lämnar den andra luckan öppen.

Börja med vad enheten faktiskt gjorde, inte med vad övervakningen påstår. systemctl status openvpn-client@office och journalctl -u openvpn-client@office -n 50 visar orsaken till avslutet och den sista raden klienten skrev innan den försvann.

Processen avslutades innan någon märkte det

En klient som försvinner utan fel har oftast avslutat medvetet. Profilen avgör det beteendet, inte tjänstehanteraren: ping-exit avslutar processen så snart motparten slutar svara, medan ping-restart behåller processen och återansluter inuti den. Sessionsgränser och inaktivitets timers ger samma bild utifrån: ingen tunnel och ingen larm.

De två ping-direktiven kan inte stå tillsammans i en profil, så välj ett och anteckna valet. Titta också på servern, för dess egen ping-exit stänger en session oavsett vad klienten bad om, och bara serverloggen registrerar vem som tog det beslutet.

Välja mellan ping-exit och ping-restart

Välj ping-restart för en bärbar dator eller en avlägsen plats som ska läka sig själv, och spara ping-exit till fall där en död tunnel måste stoppa processen så att något annat kan agera på den. Siffrorna är mindre viktiga än sambandet: ping 10 med ping-restart 60 betyder tio sekunders tystnad före en sondering och sextio före omstarten, vilket är aggressivt på en förlustdrabbad mobil länk och rimligt på en kabelansluten. Skriv skälet vid raden, annars kommer nästa läsare att anta att standardvärdena var avsiktliga.

Bekräfta sedan att det verkligen är processen som avslutades. En enhet som rapporterar aktiv medan tunneln är död är ett annat fel, som behandlas längre ner.

Övervakning som faktiskt startar om enheten

På en systemd-värd är den minsta varaktiga ändringen en enda drop-in-fil: Restart=on-failure och RestartSec=10 i /etc/systemd/system/[email protected]/restart.conf. En drop-in läses bara när systemd läser in sina egna definitioner igen, så kör systemctl daemon-reload efteråt. Verifiera med systemctl show -p Restart -p ExecMainStatus openvpn-client@office i stället för att anta att värdet kom in. Instansen i filnamnet måste vara profilen som enheten faktiskt läser in, så en fil skriven för office gör ingenting för openvpn-client@home.

on-failure ignorerar ett fall: ett rent avslut med status noll. Vissa nedmonteringsvägar slutar så, så läs den registrerade statusen i stället för att lita på formuleringen i en man-sida. Om din klient ger upp med en nolla behöver du Restart=always, och priset är att en verkligen trasig profil kommer tillbaka om och om igen tills startfrekvensgränsen slår till och journalen fylls.

Restart=always utlöses också efter ett medvetet stopp. Använd systemctl stop för underhåll och maskera enheten om den måste ligga nere medan du arbetar.

Fånga läckan medan tunneln är nere

Övervakning får tillbaka tunneln; den hindrar inte trafik från att gå ut medan tunneln saknas. persist-tun behåller enheten och dess rutter mellan återanslutningar, vilket är praktiskt och öppnar ett fönster. Enheten överlever, rutterna pekar fortfarande på den och paketen läcker ut oskyddade och orapporterade. Det är ett policyval, inte ett neutralt standardvärde.

När en värd inte får skicka oskyddade paket alls kan bara brandväggen garantera det. En utregel som tillåter tunnelgränssnittet och VPN-serverns adress medan allt annat släpps gäller fortfarande efter att klienten dör, och ingenting i klientens egen konfiguration kan filtrera trafik som klienten inte bär.

Testa det genom att stoppa klienten medvetet. Kör systemctl stop openvpn-client@office, sedan curl -m 5 https://example.com, som ska misslyckas i stället för att lyckas över den fysiska länken. En framgång betyder att brandväggsregeln saknas eller är för tillåtande.

Anslut igen, bekräfta att tunneln bär trafik på nytt och lägg först då till kontrollen i övervakningen. Att polla ip addr från cron för en tun-enhet är övervakningen som oftast misslyckas, eftersom enheten med persist-tun lever längre än sessionen och sonderingen rapporterar hälsa medan ingenting bärs.