Proč OpenVPN umírá po probuzení notebooku?

Spánek může zabít relaci OpenVPN a přitom nechat tun0. Otestujte tunel a potom restartujte jednotku z sleep hooku systemd, ne zařízení.

Uveďte stroj do režimu spánku, probuďte ho a potom v tomto pořadí zkontrolujte tři věci, než se dotknete jakékoli konfigurace: zda tun0 stále existuje, zda k němu trasa k interní adrese stále vede a zda server tohoto peer stále uvádí. Zařízení, které spánek přežije, zatímco trasa ukazuje jinam, je zbytek, ne tunel. Když je trasa správná a provoz přesto umírá, závada je nad tunelem a restart klienta to nezmění. Automatizovat restart má smysl jen poté, co ruční test ukázal, který z těch tří případů máte.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Reprodukujte probuzení, než ho zautomatizujete

Uspání ukončí šifrovanou relaci častěji, než odstraní zařízení. UDP tok, který držel tunel naživu, se zastaví, server může peer zahodit a klient si toho buď všimne a znovu se připojí, nebo si ponechá rozhraní, za nímž nic není. Kontrola rozhraní sama o sobě málo dokazuje, protože zastaralé zařízení vypadá přesně jako funkční dokud přes něj nemusí projít pakety. Spusťte vyhledání trasy a jeden skutečný požadavek přes tunel, potom si přečtěte žurnál kolem okamžiku probuzení.

Pokud se klient vrátí sám, hook přidává rozruch místo spolehlivosti. Pokud se nikdy nezotaví, automatizace je poctivé řešení.

Kde sleep hook systemd skutečně žije

Mnoho starších návodů ukazuje na /etc/pm/sleep.d, adresář vlastněný pm-utils, který uspání založené na systemd nikdy nekonzultuje. systemd čte hooky z /usr/lib/systemd/system-sleep/ a /etc/systemd/system-sleep/, předává nejprve fázi a potom operaci, takže pre a post jsou jediné hodnoty, podle kterých se hook větví. Mějte místní kopii pod /etc místo úpravy zabaleného souboru a pamatujte, že skript běží jako root uprostřed přechodu, takže se musí rychle vrátit.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart se dotkne jednotky jen tehdy, když je už aktivní, takže tunel, který jste záměrně vypnuli, zůstane vypnutý i po probuzení. --no-block brání hooku čekat, zatímco klient vyjednává, což je důležité, když síť ještě není nahoru. Společně oba příznaky znamenají hook, který tiše selže, místo aby zdržel celou sekvenci probuzení. Když je jednotka už zastavená, nestane se vůbec nic, což je přesně výsledek, který tam chcete.

Obnovte službu, nechte tun0 na pokoji

Ruční shození tun0 nechá démona dohlížet na rozhraní, které už nevlastní, a další změna stavu vytvoří matoucí chyby. Zacilte na službu nebo její profil připojení, ne na rozhraní; nejprve zkontrolujte přesný název jednotky, protože distribuční balíčky, OpenVPN 3 a NetworkManager volí různé. Profil NetworkManager se vrátí, když se toto připojení zacyklí, takže jednotka systemd tam není cíl. Ať je mechanismus jakýkoli, měla by to být stejná akce, kterou jste ověřili ručně.

Restart znovu nainstaluje trasy, které klient přitlačil při připojení. Většina probuzení to chce. Stroj, kde jste přidali vlastní cesty, ne, takže je znovu zkontrolujte, místo abyste předpokládali, že obnova je vrátila, a zapište je tam, kde je příští probuzení najde.

Zvládněte časování, které nemůžete ovládat

Bezdrátové přidružení a DHCP často skončí až po spuštění hooku, takže restart může selhat, zatímco cesta k serveru ještě neexistuje. Krátce počkejte na tuto adresu, zkuste to jednou znovu a výsledek zalogujte.

Překlad jmen je samostatný závod, protože síťový stack plochy může obnovit DNS poté, co je tunel už nahoře. Testujte dotazy zvlášť s resolvectl query internal.example místo odvozování z funkční trasy. Tunel, který správně směruje a nic nepřekládá, je problém DNS, ne problém hooku.

Udržujte rozhodnutí hooku viditelné tím, že zapíšete fázi, název jednotky a výsledek do žurnálu. Poznamenejte si do poznámek stroje, který test probuzení jste spustili, aby se funkční obnova dala rozeznat od šťastné. Zvolte nejméně rušivou akci, která vrátí službu, a nechte klienta, který se obnoví sám, ať to udělá. Úplný restart zahodí běžící relace, což je skutečná cena na notebooku, který se probouzí několikrát denně.

Související články