Zakaj vaš odjemalec OpenVPN ostane izklopljen po eni sami časovni omejitvi

Ponedeljkovo jutro: tunel, ki se je dvignil v petek, je izginil, vmesnik je še vedno na seznamu in v dnevniku ni ničesar o tem, da bi kdo to opazil. Gostitelj je povezan, nadzorna plošča je zelena in vse, kar je poslal čez vikend, je šlo skozi fizični vmesnik. Tu manjkata dve neodvisni odločitvi: ena o tem, ali proces odjemalca preživi prehodno napako, in druga o tem, ali kaj nad njim proces po izhodu znova zažene. Popravilo samo ene pusti drugo vrzel odprto.

Začnite s tem, kar je enota v resnici naredila, ne s tem, kar trdi spremljanje. systemctl status openvpn-client@office in journalctl -u openvpn-client@office -n 50 prikažeta razlog izhoda in zadnjo vrstico, ki jo je odjemalec zapisal pred odhodom.

Proces se je končal, preden je kdo opazil

Odjemalec, ki izgine brez napake, je običajno izstopil namerno. To vedenje določa profil, ne upravitelj storitev: ping-exit konča proces takoj, ko se nasprotna stran neha odzivati, medtem ko ping-restart proces obdrži in se v njem znova poveže. Omejitve seje in časovniki nedejavnosti od zunaj dajejo enako sliko: brez tunela in brez alarma.

Dve direktivi ping ne moreta biti skupaj v enem profilu, zato izberite eno in izbiro zabeležite. Poglejte tudi strežnik, ker njegov lastni ping-exit zapre sejo ne glede na to, kaj je zahteval odjemalec, in samo dnevnik strežnika zabeleži, kdo je sprejel to odločitev.

Izbira med ping-exit in ping-restart

Izberite ping-restart za prenosnik ali oddaljeno lokacijo, ki se mora sama pozdraviti, ping-exit pa prihranite za primere, ko mora mrtev tunel ustaviti proces, da lahko kaj drugega ukrepa. Številke so manj pomembne od razmerja: ping 10 s ping-restart 60 pomeni deset sekund tišine pred preizkusom in šestdeset pred ponovnim zagonom, kar je agresivno na izgubni mobilni povezavi in razumno na žični. Razlog zapišite ob vrstico, sicer bo naslednji bralec domneval, da so bile privzete vrednosti namerne.

Nato potrdite, da je res izstopil proces. Enota, ki poroča o aktivnosti, medtem ko je tunel mrtev, je druga napaka, obravnavana spodaj.

Nadzor, ki enoto resnično znova zažene

Na gostitelju systemd je najmanjša trajna sprememba ena datoteka drop-in: Restart=on-failure in RestartSec=10 v /etc/systemd/system/[email protected]/restart.conf. Drop-in se prebere le, ko systemd znova naloži lastne definicije, zato po tem zaženite systemctl daemon-reload. Preverite z systemctl show -p Restart -p ExecMainStatus openvpn-client@office, namesto da bi domnevali, da je vrednost prispela. Primerek v imenu datoteke mora biti profil, ki ga enota v resnici naloži, zato datoteka, napisana za office, ne naredi ničesar za openvpn-client@home.

on-failure prezre en primer: čist izhod s statusom nič. Nekatere poti razgradnje se končajo tako, zato preberite zabeleženi status, namesto da bi zaupali formulaciji strani priročnika. Če vaš odjemalec obupa z ničlo, potrebujete Restart=always, cena pa je, da se resnično pokvarjen profil vrača znova in znova, dokler ne pride do omejitve hitrosti zagona in se dnevnik ne napolni.

Restart=always se sproži tudi po namerni ustavitvi. Za vzdrževanje uporabite systemctl stop in enoto maskirajte, če mora ostati ustavljena, medtem ko delate.

Ujemite uhajanje, medtem ko je tunel ustavljen

Nadzor vrne tunel; ne preprečuje prometu, da bi odhajal, medtem ko tunela ni. persist-tun ohrani napravo in njene poti med ponovnimi povezavami, kar je priročno in odpre okno. Naprava preživi, poti še vedno kažejo nanjo in paketi odtekajo nezaščiteni in neprijavljeni. To je odločitev politike, ne nevtralna privzeta vrednost.

Ko gostitelj sploh ne sme pošiljati nezaščitenih paketov, lahko to zagotovi le požarni zid. Izstopno pravilo, ki dovoli vmesnik tunela in naslov strežnika VPN ter zavrže vse ostalo, velja tudi po smrti odjemalca in nič v konfiguraciji odjemalca samega ne more filtrirati prometa, ki ga odjemalec ne prenaša.

Preizkusite tako, da odjemalec namerno ustavite. Zaženite systemctl stop openvpn-client@office, nato curl -m 5 https://example.com, ki bi moral prek fizične povezave spodleteti, ne uspeti. Uspeh pomeni, da pravilo požarnega zidu manjka ali je preveč popustljivo.

Znova se povežite, potrdite, da tunel spet prenaša promet, in šele nato dodajte preverjanje spremljanju. Anketiranje ip addr iz cron za napravo tun je nadzor, ki najpogosteje zataji, ker z persist-tun naprava preživi sejo in preverjanje poroča o zdravju, medtem ko se nič ne prenaša.