Prečo váš klient OpenVPN zostane vypnutý po jedinom časovom limite

Pondelkové ráno: tunel, ktorý sa v piatok zdvihol, je preč, rozhranie je stále v zozname a v žurnáli nie je nič o tom, že by si to niekto všimol. Hostiteľ je online, panel je zelený a všetko, čo cez víkend odoslal, vyšlo cez fyzické rozhranie. Chýbajú tu dve nezávislé rozhodnutia: jedno o tom, či proces klienta prežije prechodnú poruchu, a druhé o tom, či niečo nad ním proces po ukončení znova spustí. Oprava len jedného necháva druhú medzeru otvorenú.

Začnite tým, čo jednotka skutočne urobila, nie tým, čo tvrdí monitorovanie. systemctl status openvpn-client@office a journalctl -u openvpn-client@office -n 50 ukazujú dôvod ukončenia a posledný riadok, ktorý klient zapísal pred odchodom.

Proces skončil skôr, než si to niekto všimol

Klient, ktorý zmizne bez chyby, zvyčajne skončil úmyselne. Toto správanie určuje profil, nie správca služieb: ping-exit ukončí proces hneď, ako protistrana prestane odpovedať, zatiaľ čo ping-restart proces ponechá a znova sa v ňom pripojí. Limity relácie a časovače nečinnosti vytvárajú zvonku rovnaký obraz: žiadny tunel a žiadny alarm.

Obe direktívy ping nemôžu byť v jednom profile súčasne, preto jednu vyberte a voľbu zaznamenajte. Pozrite sa aj na server, pretože jeho vlastný ping-exit zatvorí reláciu bez ohľadu na to, čo klient požadoval, a kto to nariadil, zaznamenáva len protokol servera.

Voľba medzi ping-exit a ping-restart

Zvoľte ping-restart pre notebook alebo vzdialené pracovisko, ktoré sa má samo zaholiť, a ping-exit si nechajte na prípady, keď mŕtvy tunel musí zastaviť proces, aby na to mohlo zareagovať niečo iné. Čísla sú menej dôležité ako vzťah: ping 10 s ping-restart 60 znamená desať sekúnd ticha pred sondou a šesťdesiat pred reštartom, čo je agresívne na stratovom mobilnom spoji a rozumné na káblovom. Napíšte dôvod vedľa riadku, inak ďalší čitateľ bude predpokladať, že predvolené hodnoty boli zámerné.

Potom potvrďte, že skončil skutočne proces. Jednotka, ktorá hlási aktivitu, kým je tunel mŕtvy, je iná porucha, rozobraná nižšie.

Dohľad, ktorý jednotku skutočne reštartuje

Na hostiteľovi so systemd je najmenšou trvalou zmenou jeden súbor drop-in: Restart=on-failure a RestartSec=10 v /etc/systemd/system/[email protected]/restart.conf. Drop-in sa načíta len vtedy, keď systemd znova načíta vlastné definície, preto potom spustite systemctl daemon-reload. Overte pomocou systemctl show -p Restart -p ExecMainStatus openvpn-client@office, namiesto toho, aby ste predpokladali, že hodnota dorazila. Inštancia v názve súboru musí byť profil, ktorý jednotka skutočne načítava, takže súbor napísaný pre office nerobí nič pre openvpn-client@home.

on-failure ignoruje jeden prípad: čisté ukončenie so stavom nula. Niektoré cesty rozobratia končia takto, preto čítajte zaznamenaný stav, namiesto toho, aby ste verili formulácii manuálovej stránky. Ak váš klient skončí s nulou, potrebujete Restart=always, a cenou je, že skutočne pokazený profil sa vracia znova a znova, kým nezaberie limit rýchlosti spúšťania a žurnál sa nenaplní.

Restart=always sa spustí aj po úmyselnom zastavení. Na údržbu použite systemctl stop a jednotku maskujte, ak musí zostať zastavená, kým pracujete.

Zachyťte únik, kým je tunel dole

Dohľad vracia tunel späť, ale nebráni prevádzke odchádzať, kým tunel chýba. persist-tun udržiava zariadenie a jeho trasy medzi opätovnými pripojeniami, čo je pohodlné a otvára okno. Zariadenie prežije, trasy naň stále mieria a pakety odtekajú nechránené a nenahlásené. To je rozhodnutie o politike, nie neutrálna predvolená hodnota.

Keď hostiteľ nesmie vôbec vysielať nechránené pakety, môže to zaručiť len firewall. Výstupné pravidlo, ktoré povolí rozhranie tunela a adresu VPN servera a všetko ostatné zahodí, platí aj po smrti klienta a nič vo vlastnej konfigurácii klienta nemôže filtrovať prevádzku, ktorú klient nenáša.

Otestujte to úmyselným zastavením klienta. Spustite systemctl stop openvpn-client@office, potom curl -m 5 https://example.com, ktorý by cez fyzické spojenie mal zlyhať, nie uspieť. Úspech znamená, že pravidlo firewallu chýba alebo je príliš benevolentné.

Znova sa pripojte, potvrďte, že tunel opäť prenáša prevádzku, a až potom pridajte kontrolu do monitorovania. Dotazovanie ip addr z cronu na zariadenie tun je dohľad, ktorý zlyháva najčastejšie, pretože s persist-tun zariadenie prežije reláciu a sonda hlási zdravie, kým sa nič neprenáša.