Kvifor OpenVPN-klienten din blir liggjande nede etter éin einaste tidsavbrot

Måndags morgon: tunnelen som kom opp på fredag er borte, grensesnittet står framleis i lista, og ingenting i journalen seier at nokon la merke til det. Verten er pålogga, dashbordet er grønt, og alt han sende i helga gjekk ut gjennom det fysiske grensesnittet i staden. Her manglar to uavhengige avgjerder: éi om klientprosessen overlever ein forbigåande feil, og éi om noko over han startar prosessen på nytt etter at han avsluttar. Å retta berre éi av dei lèt den andre sprekka stå open.

Start med det eininga faktisk gjorde, ikkje med det overvakinga hevdar. systemctl status openvpn-client@office og journalctl -u openvpn-client@office -n 50 viser årsaka til avsluttinga og den siste linja klienten skreiv før han forsvann.

Prosessen avslutta før nokon la merke til det

Ein klient som forsvinn utan feil, har som regel avslutta med vilje. Profilen avgjer denne åtferda, ikkje tenesteadministratoren: ping-exit avsluttar prosessen så snart motparten sluttar å svara, medan ping-restart held på prosessen og koplar til på nytt inne i han. Øktgrenser og inaktivitetsur gjev det same bildet utanfrå: ingen tunnel og ingen alarm.

Dei to ping-direktiva kan ikkje stå saman i éin profil, så vel eitt og noter valet. Sjå på tenaren òg, for hans eigen ping-exit lukkar ei økt uansett kva klienten bad om, og berre tenarloggen registrerer kven som tok den avgjerda.

Velje mellom ping-exit og ping-restart

Vel ping-restart for ein berbar maskin eller ein avsides stad som skal lækja seg sjølv, og spar ping-exit til tilfelle der ein død tunnel må stoppa prosessen slik at noko anna kan handle på han. Tala tyder mindre enn samanhengen: ping 10 med ping-restart 60 tyder ti sekund stilla før ei sondering og seksti før omstarten, noko som er aggressivt på ei tapande mobil lenkje og rimeleg på ei kabelbasert. Skriv grunngjevinga ved linja, elles vil neste lesar gå ut frå at standardverdiane var medvite valde.

Stadfest deretter at det verkeleg er prosessen som avslutta. Ei eining som rapporterer aktiv medan tunnelen er død, er ein annan feil, handsama lenger nede.

Overvaking som faktisk startar eininga på nytt

På ein systemd-vert er den minste varige endringa éi drop-in-fil: Restart=on-failure og RestartSec=10 i /etc/systemd/system/[email protected]/restart.conf. Ei drop-in blir berre lesen når systemd lastar inn sine eigne definisjonar på nytt, så køyr systemctl daemon-reload etterpå. Stadfest med systemctl show -p Restart -p ExecMainStatus openvpn-client@office i staden for å gå ut frå at verdien kom inn. Instansen i filnamnet må vere profilen eininga faktisk lastar, så ei fil skriven for office gjer ingenting for openvpn-client@home.

on-failure ignorerer eitt tilfelle: ei rein avslutting med status null. Nokre nedrivingsvegar endar slik, så les den registrerte statusen i staden for å stole på ordlyden i ein man-side. Viss klienten din gjev opp med ein null, treng du Restart=always, og prisen er at ein verkeleg øydelagd profil kjem tilbake om og om igjen til startraten slår inn og journalen blir full.

Restart=always blir også utløyst etter ein medviten stopp. Bruk systemctl stop til vedlikehald, og masker eininga om ho må vere nede medan du arbeider.

Fang lekkasjen medan tunnelen er nede

Overvaking får tunnelen tilbake; ho hindrar ikkje trafikk i å gå ut medan tunnelen er borte. persist-tun held på eininga og rutene hennar gjennom attilkoplingar, noko som er praktisk og opnar eit vindauge. Eininga overlever, rutene peikar framleis på henne, og pakkar silar ut uverja og urapportert. Det er eit policyval, ikkje ein nøytral standardverdi.

Når ein vert ikkje under noko omstende skal senda uverja pakkar, kan berre brannmuren garantere det. Ei utgangsregel som tillèt tunnelgrensesnittet og adressa til VPN-tenaren medan ho slepp alt anna, gjeld framleis etter at klienten døyr, og ingenting i konfigurasjonen til klienten sjølv kan filtrere trafikk klienten ikkje ber.

Test det ved å stoppa klienten med vilje. Køyr systemctl stop openvpn-client@office, deretter curl -m 5 https://example.com, som skal feile i staden for å lukkast over den fysiske lenkja. Ein suksess tyder at brannmurregelen manglar eller er for ettergjevande.

Kopla til på nytt, stadfest at tunnelen ber trafikk igjen, og legg først då til kontrollen i overvakinga. Å polle ip addr frå cron for eininga tun er overvakinga som oftast feilar, fordi eininga med persist-tun lever lenger enn økta, og sonderinga rapporterer helse medan ingenting blir bore.