systemd zastaví službu VPN: slaďte Type= s klientem

VPN jednotka spouštěná při bootu přejde do neaktivního stavu, když Type= neodpovídá životnosti klienta. Slaďte typ, opravte vlastnictví a seřaďte službu za tunel.

Jednotky mohou vypadat správně, systemctl start může hlásit úspěch a o deset sekund později služba stojí neaktivní. Nebo se restartuje každou půlminutu, dokud ji nezastaví limit spuštění. Ani jedno z chování není závada sítě: jednotka popisuje životnost procesu, která neodpovídá tomu, co klient skutečně dělá. Klient může forknout a skončit, nebo nakonfigurovat relaci a okamžitě skončit.

Proč jednotka přejde do neaktivního stavu několik sekund po úspěšném spuštění

systemd odvozuje stav od procesu, který spustil, takže Type= je tvrzení o tomto procesu, ne dokumentace. S Type=simple se jednotka počítá jako aktivní, dokud příkaz běží, a přejde do neaktivního stavu, když se vrátí. Klient, který předá připojení pomocnému programu a skončí, proto vypadá jako pád, i když tunel běží. Journal pak ukazuje vzor start-stop, který se čte jako vadná binárka.

Přečtěte si typ jednotky vedle chování klienta, než sáhnete na konfiguraci sítě.

Zvolte typ, který odpovídá klientovi

Dva vzory pokrývají většinu CLI od dodavatelů: příkaz, který nakonfiguruje relaci a skončí, a příkaz, který před návratem forku pomocný program. Každý potřebuje jiný tvar jednotky.

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot s RemainAfterExit=true udrží jednotku aktivní i po návratu příkazu, což odpovídá vzoru nakonfiguruj-a-skonči, a zastavovací příkaz dá službě čisté ukončení. Forkující klient si zachová stejný tvar, ale potřebuje Type=forking, aby systemd sledoval potomka. Nastavte Restart=on-failure, RestartSec=30 a konečný StartLimitBurst, aby se výpadek poskytovatele neproměnil ve smyčku restartů, která chybu zahrabe.

Nikdy nedovolte, aby hlídaný klient démonizoval

Dohlížecí nástroje mimo systemd narážejí na stejnou zeď. Skript runit, který spustí démonizovaného klienta, se okamžitě vrátí dohlížeči, ten návrat přečte jako pád a spustí další kopii. Každý dohlížeč očekává, že vlastní proces v popředí, tak jako sshd -D zůstává vpředu. U hlídaných příkazů zrušte přepínač démona a nechte práci na pozadí na dohlížeči. Obalové skripty, které se vrátí dřív, než tunel existuje, způsobují stejný zmatek.

Proces, který se odpojí sám od sebe, je neviditelný pro všechno, co ho mělo hlídat.

Relace skončí a odnese tunel s sebou

Relace plochy vlastní klienta, kterého spustí. Ukončete přihlášení a sběrnice relace zmizí, odnese tunel s sebou, což vysvětluje, proč připojení grafického klienta často spadne, když se zavře poslední okno. Servery by měly používat systémovou jednotku nebo profil NetworkManager, který se zvedne sám. Uživatelská jednotka má smysl jen tehdy, když má tunel skončit s přihlášením, proto ji připněte k cíli grafické relace a napište to do popisu.

Uživatel služby je druhá polovina stejného problému. Klíč vlastněný rootem s režimem 0600 je pro jednotku běžící pod jiným účtem nečitelný, ať sudo ve vašem shellu dokázalo cokoli.

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

Seřaďte závislé až poté, co adresa existuje

Když se démon naváže na adresu tunelu, která ještě není vytvořená, skončí s Cannot assign requested address. Opravou je výslovné řazení, ne smyčka opakovaných pokusů.

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

After= seřadí úlohy, zatímco Requires= u jednotky zařízení váže závislý proces na existenci rozhraní, což je silnější než čekat jen na síťový cíl. Po úpravě znovu načtěte správce a restartujte závislou službu, pak si přečtěte její journal, místo abyste předpokládali, že pořadí zabralo. Posílejte výstup klienta do journalu přes StandardOutput=journal nebo volbu logování, protože hlídaný klient, který píše do souboru, jejž nikdo neotevře, vypadá stejně jako ten, který se nikdy nespustil.

Pak jednou restartujte a potvrďte, že jednotka je aktivní poté, co se zařízení tunelu objeví. Oprava ověřená jen pomocí systemctl start neotestovala bootovací pořadí, které měla opravit.

Související články