Proč váš klient OpenVPN zůstane vypnutý po jediném časovém limitu

Pondělní ráno: tunel, který se v pátek zvedl, je pryč, rozhraní je stále v seznamu a v žurnálu není nic o tom, že by si toho někdo všiml. Hostitel je online, panel je zelený a vše, co o víkendu odeslal, vyšlo přes fyzické rozhraní. Chybí zde dvě nezávislá rozhodnutí: jedno o tom, zda proces klienta přežije přechodnou poruchu, a druhé o tom, zda něco nad ním proces po ukončení znovu spustí. Oprava jen jednoho z nich nechává druhou mezeru otevřenou.

Začněte tím, co jednotka skutečně udělala, ne tím, co tvrdí monitorování. systemctl status openvpn-client@office a journalctl -u openvpn-client@office -n 50 ukazují důvod ukončení a poslední řádek, který klient zapsal před odchodem.

Proces skončil, než si toho někdo všiml

Klient, který zmizí bez chyby, obvykle skončil úmyslně. Toto chování určuje profil, ne správce služeb: ping-exit ukončí proces, jakmile protějšek přestane odpovídat, zatímco ping-restart proces ponechá a znovu se v něm připojí. Limity relace a časovače nečinnosti vytvářejí zvenčí stejný obraz: žádný tunel a žádný alarm.

Obě direktivy ping nemohou být v jednom profilu současně, proto jednu vyberte a volbu zaznamenejte. Podívejte se i na server, protože jeho vlastní ping-exit uzavře relaci bez ohledu na to, co klient požadoval, a kdo to nařídil, zaznamenává jen protokol serveru.

Volba mezi ping-exit a ping-restart

Zvolte ping-restart pro notebook nebo vzdálené pracoviště, které se má samo zahojit, a ping-exit si nechte pro případy, kdy mrtvý tunel musí zastavit proces, aby na to mohlo zareagovat něco jiného. Čísla jsou méně důležitá než vztah: ping 10 s ping-restart 60 znamená deset sekund ticha před sondou a šedesát před restartem, což je agresivní na ztrátovém mobilním spoji a rozumné na kabelovém. Napište důvod vedle řádku, jinak další čtenář bude předpokládat, že výchozí hodnoty byly záměrné.

Poté potvrďte, že skutečně skončil proces. Jednotka, která hlásí aktivitu, zatímco tunel je mrtvý, je jiná porucha, probraná níže.

Dohled, který jednotku skutečně restartuje

Na hostiteli se systemd je nejmenší trvalou změnou jeden soubor drop-in: Restart=on-failure a RestartSec=10 v /etc/systemd/system/[email protected]/restart.conf. Drop-in se načte jen tehdy, když systemd znovu načte vlastní definice, proto poté spusťte systemctl daemon-reload. Ověřte pomocí systemctl show -p Restart -p ExecMainStatus openvpn-client@office, místo abyste předpokládali, že hodnota dorazila. Instance v názvu souboru musí být profil, který jednotka skutečně načítá, takže soubor napsaný pro office nic nedělá pro openvpn-client@home.

on-failure ignoruje jeden případ: čisté ukončení se stavem nula. Některé cesty rozebrání končí takto, proto čtěte zaznamenaný stav, místo abyste věřili formulaci manuálové stránky. Pokud váš klient skončí s nulou, potřebujete Restart=always, a cenou je, že skutečně rozbitý profil se vrací znovu a znovu, dokud nezabere limit rychlosti spouštění a žurnál se nenaplní.

Restart=always se spustí i po úmyslném zastavení. Pro údržbu použijte systemctl stop a jednotku maskujte, pokud musí zůstat zastavená, dokud pracujete.

Zachyťte únik, dokud je tunel dole

Dohled vrací tunel zpět, ale nebrání provozu odcházet, dokud tunel chybí. persist-tun udržuje zařízení a jeho trasy mezi opětovnými připojeními, což je pohodlné a otevírá okno. Zařízení přežije, trasy na něj stále míří a pakety odtékají nechráněné a nenahlášené. To je rozhodnutí o politice, ne neutrální výchozí hodnota.

Když hostitel nesmí vůbec vysílat nechráněné pakety, může to zaručit jen firewall. Výstupní pravidlo, které povolí rozhraní tunelu a adresu VPN serveru a vše ostatní zahodí, platí i po smrti klienta a nic ve vlastní konfiguraci klienta nemůže filtrovat provoz, který klient nenese.

Otestujte to úmyslným zastavením klienta. Spusťte systemctl stop openvpn-client@office, poté curl -m 5 https://example.com, což by přes fyzické spojení mělo selhat, ne uspět. Úspěch znamená, že pravidlo firewallu chybí nebo je příliš benevolentní.

Znovu se připojte, potvrďte, že tunel opět nese provoz, a teprve potom přidejte kontrolu do monitorování. Dotazování ip addr z cronu na zařízení tun je dohled, který selhává nejčastěji, protože s persist-tun zařízení přežije relaci a sonda hlásí zdraví, zatímco se nic nepřenáší.