Zašto vaš OpenVPN klijent ostaje ugašen nakon jednog isteka vremena

Ponedjeljak ujutro: tunel koji se podigao u petak je nestao, sučelje se još navodi, a u dnevniku ne piše da je itko to primijetio. Host je na mreži, nadzorna ploča je zelena, a sve što je poslao tijekom vikenda izašlo je kroz fizičko sučelje. Ovdje nedostaju dvije neovisne odluke: jedna o tome preživljava li proces klijenta prolazni kvar i jedna o tome pokreće li nešto iznad njega proces ponovno nakon izlaska. Popravak samo jedne od njih ostavlja drugu prazninu otvorenom.

Pođite od onoga što je jedinica stvarno učinila, a ne od onoga što tvrdi nadzor. systemctl status openvpn-client@office i journalctl -u openvpn-client@office -n 50 pokazuju razlog izlaska i zadnji redak koji je klijent napisao prije odlaska.

Proces je izašao prije nego što je itko primijetio

Klijent koji nestane bez greške obično je izašao namjerno. To ponašanje određuje profil, a ne upravitelj usluga: ping-exit završava proces čim druga strana prestane odgovarati, dok ping-restart zadržava proces i ponovno se povezuje unutar njega. Ograničenja sesije i mjerači vremena nedjelovanja izvana daju istu sliku: bez tunela i bez alarma.

Dvije se ping direktive ne mogu naći zajedno u jednom profilu, zato odaberite jednu i zapišite odluku. Pogledajte i poslužitelj, jer njegov vlastiti ping-exit zatvara sesiju bez obzira na to što je klijent zatražio, a samo poslužiteljev dnevnik bilježi tko je to naredio.

Odabir između ping-exit i ping-restart

Odaberite ping-restart za prijenosno računalo ili udaljeno mjesto koje se treba samo popraviti, a ping-exit čuvajte za slučajeve u kojima mrtav tunel mora zaustaviti proces kako bi nešto drugo na to moglo reagirati. Brojevi su manje važni od odnosa: ping 10 s ping-restart 60 znači deset sekundi tišine prije provjere i šezdeset prije ponovnog pokretanja, što je agresivno na mobilnoj vezi s gubicima, a razumno na žičanoj. Zapišite razlog uz redak, jer će inače sljedeći čitatelj pretpostaviti da su zadane vrijednosti bile namjerne.

Zatim potvrdite da je doista proces ono što je izašlo. Jedinica koja prijavljuje aktivnost dok je tunel mrtav drugi je kvar koji se obrađuje niže.

Nadzor koji doista ponovno pokreće jedinicu

Na systemd hostu najmanja trajna promjena je jedna drop-in datoteka: Restart=on-failure i RestartSec=10 u /etc/systemd/system/[email protected]/restart.conf. Drop-in se čita samo kad systemd ponovno učita vlastite definicije, zato nakon toga pokrenite systemctl daemon-reload. Provjerite pomoću systemctl show -p Restart -p ExecMainStatus openvpn-client@office umjesto da pretpostavite da je vrijednost stigla. Instanca u nazivu datoteke mora biti profil koji jedinica doista učitava, pa datoteka napisana za office ne radi ništa za openvpn-client@home.

on-failure zanemaruje jedan slučaj: čist izlazak sa statusom nula. Neki putovi rastavljanja završavaju tako, zato čitajte zabilježeni status umjesto da vjerujete formulaciji priručnika. Ako vaš klijent odustane s nulom, treba vam Restart=always, a cijena je da se doista pokvaren profil vraća iznova dok se ne aktivira ograničenje brzine pokretanja i dnevnik se ne napuni.

Restart=always aktivira se i nakon namjernog zaustavljanja. Koristite systemctl stop za održavanje i maskirajte jedinicu ako mora ostati zaustavljena dok radite.

Uhvatite curenje dok je tunel zaustavljen

Nadzor vraća tunel, ali ne sprječava promet da izađe dok tunela nema. persist-tun zadržava uređaj i njegove rute između ponovnih povezivanja, što je zgodno i otvara prozor. Uređaj preživi, rute i dalje pokazuju na njega, a paketi otječu nezaštićeni i neprijavljeni. To je odluka politike, a ne neutralna zadana vrijednost.

Kad host uopće ne smije ispuštati nezaštićene pakete, samo to može jamčiti vatrozid. Izlazno pravilo koje dopušta sučelje tunela i adresu VPN poslužitelja, a odbacuje sve ostalo, vrijedi i nakon smrti klijenta, i ništa u vlastitoj konfiguraciji klijenta ne može filtrirati promet koji klijent ne nosi.

Testirajte to namjernim zaustavljanjem klijenta. Pokrenite systemctl stop openvpn-client@office, zatim curl -m 5 https://example.com, što bi trebalo pasti, a ne uspjeti preko fizičke veze. Uspjeh znači da pravilo vatrozida nedostaje ili je previše popustljivo.

Ponovno se povežite, potvrdite da tunel opet nosi promet i tek tada dodajte provjeru u nadzor. Anketiranje ip addr preko cron-a za tun uređaj je nadzor koji najčešće zakaže, jer s persist-tun uređaj živi dulje od sesije, a provjera javlja zdravlje dok se ništa ne prenosi.