Hvorfor OpenVPN-klienten din blir liggende nede etter én enkelt tidsavbrudd

Mandags morgen: tunnelen som kom opp på fredag er borte, grensesnittet står fortsatt i listen, og ingenting i journalen sier at noen la merke til det. Verten er pålogget, dashbordet er grønt, og alt den sendte i helgen gikk ut gjennom det fysiske grensesnittet i stedet. Her mangler to uavhengige beslutninger: én om hvorvidt klientprosessen overlever en forbigående feil, og én om hvorvidt noe over den starter prosessen på nytt etter at den avsluttes. Å rette bare én av dem lar den andre sprekken stå åpen.

Start med det enheten faktisk gjorde, ikke med det overvåkingen hevder. systemctl status openvpn-client@office og journalctl -u openvpn-client@office -n 50 viser årsaken til avslutningen og den siste linjen klienten skrev før den forsvant.

Prosessen avsluttet før noen la merke til det

En klient som forsvinner uten feil, har som regel avsluttet med vilje. Profilen bestemmer denne atferden, ikke tjenesteadministratoren: ping-exit avslutter prosessen så snart motparten slutter å svare, mens ping-restart beholder prosessen og kobler til på nytt inne i den. Øktgrenser og inaktivitetsur gir det samme bildet utenfra: ingen tunnel og ingen alarm.

De to ping-direktivene kan ikke stå sammen i én profil, så velg ett og noter valget. Se på serveren også, for dens egen ping-exit lukker en økt uansett hva klienten ba om, og bare serverloggen registrerer hvem som tok den beslutningen.

Velge mellom ping-exit og ping-restart

Velg ping-restart for en bærbar maskin eller et fjerntliggende sted som skal hele seg selv, og spar ping-exit til tilfeller der en død tunnel må stoppe prosessen slik at noe annet kan handle på den. Tallene betyr mindre enn sammenhengen: ping 10 med ping-restart 60 betyr ti sekunder stillhet før en sondering og seksti før omstarten, noe som er aggressivt på en tapende mobil lenke og rimelig på en kablet. Skriv begrunnelsen ved linjen, ellers vil neste leser anta at standardverdiene var bevisste.

Bekreft deretter at det virkelig er prosessen som avsluttet. En enhet som rapporterer aktiv mens tunnelen er død, er en annen feil, behandlet lenger ned.

Overvåking som faktisk starter enheten på nytt

På en systemd-vert er den minste varige endringen én drop-in-fil: Restart=on-failure og RestartSec=10 i /etc/systemd/system/[email protected]/restart.conf. En drop-in leses bare når systemd laster inn sine egne definisjoner på nytt, så kjør systemctl daemon-reload etterpå. Bekreft med systemctl show -p Restart -p ExecMainStatus openvpn-client@office i stedet for å anta at verdien kom inn. Instansen i filnavnet må være profilen enheten faktisk laster, så en fil skrevet for office gjør ingenting for openvpn-client@home.

on-failure ignorerer ett tilfelle: en ren avslutning med status null. Noen nedrivningsveier ender slik, så les den registrerte statusen i stedet for å stole på ordlyden i en man-side. Hvis klienten din gir opp med en null, trenger du Restart=always, og prisen er at en virkelig ødelagt profil kommer tilbake igjen og igjen til startraten slår inn og journalen fylles.

Restart=always utløses også etter en bevisst stopp. Bruk systemctl stop for vedlikehold, og masker enheten hvis den må være nede mens du arbeider.

Fang lekkasjen mens tunnelen er nede

Overvåking får tunnelen tilbake; den hindrer ikke trafikk i å gå ut mens tunnelen er borte. persist-tun beholder enheten og rutene dens gjennom gjenoppkoblinger, noe som er praktisk og åpner et vindu. Enheten overlever, rutene peker fortsatt på den, og pakker siver ut ubeskyttet og urapportert. Det er et policyvalg, ikke en nøytral standardverdi.

Når en vert ikke under noen omstendighet skal sende ubeskyttede pakker, kan bare brannmuren garantere det. En utgangsregel som tillater tunnelgrensesnittet og adressen til VPN-serveren mens den slipper alt annet, gjelder fortsatt etter at klienten dør, og ingenting i klientens egen konfigurasjon kan filtrere trafikk klienten ikke bærer.

Test det ved å stoppe klienten med vilje. Kjør systemctl stop openvpn-client@office, deretter curl -m 5 https://example.com, som skal feile i stedet for å lykkes over den fysiske lenken. En suksess betyr at brannmurregelen mangler eller er for ettergivende.

Koble til på nytt, bekreft at tunnelen bærer trafikk igjen, og først da legg til kontrollen i overvåkingen. Å polle ip addr fra cron for en tun-enhet er overvåkingen som oftest feiler, fordi enheten med persist-tun lever lenger enn økten, og sonderingen rapporterer sunnhet mens ingenting bæres.