systemd zastaví službu VPN: zlaďte Type= s klientom

VPN jednotka pri štarte prejde do neaktívneho stavu, keď Type= nezodpovedá životnosti klienta. Zlaďte typ, opravte vlastníctvo a zoraďte službu za tunelom.

Jednotky môžu vyzerať správne, systemctl start môže hlásiť úspech a o desať sekúnd služba stojí neaktívna. Alebo sa reštartuje každú polminútu, kým ju nezastaví limit spustení. Ani jedno správanie nie je porucha siete: jednotka opisuje životnosť procesu, ktorá nezodpovedá tomu, čo klient skutočne robí. Klient môže forknúť a skončiť, alebo nakonfigurovať reláciu a okamžite skončiť.

Prečo jednotka prejde do neaktívneho stavu niekoľko sekúnd po úspešnom spustení

systemd odvodzuje stav z procesu, ktorý spustil, takže Type= je tvrdenie o tomto procese, nie dokumentácia. S Type=simple sa jednotka počíta ako aktívna, kým príkaz beží, a prejde do neaktívneho stavu, keď sa vráti. Klient, ktorý odovzdá pripojenie pomocnému programu a skončí, preto vyzerá ako pád, aj keď tunel beží. Journal potom ukazuje vzor štart-stop, ktorý sa číta ako chybná binárka.

Prečítajte si typ jednotky vedľa správania klienta, skôr než siahnete na konfiguráciu siete.

Zvoľte typ, ktorý zodpovedá klientovi

Dva vzory pokrývajú väčšinu CLI od dodávateľov: príkaz, ktorý nakonfiguruje reláciu a skončí, a príkaz, ktorý pred návratom vytvorí potomka s pomocným programom. Každý potrebuje iný 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 aktívnu aj po návrate príkazu, čo zodpovedá vzoru nakonfiguruj a skonči, a zastavovací príkaz dáva službe čisté ukončenie. Klient, ktorý vytvára potomka, si zachová rovnaký tvar, ale potrebuje Type=forking, aby systemd sledoval potomka. Nastavte Restart=on-failure, RestartSec=30 a konečný StartLimitBurst, aby sa výpadok poskytovateľa nezmenil na slučku reštartov, ktorá chybu zahrabe.

Nikdy nedovoľte, aby hlídaný klient démonizoval

Dozorné nástroje mimo systemd narážajú na tú istú stenu. Skript runit, ktorý spustí démonizovaného klienta, sa okamžite vráti dozorcu, ten návrat prečíta ako pád a spustí ďalšiu kópiu. Každý dozorca očakáva, že vlastní proces v popredí, tak ako sshd -D zostáva vpredu. Pri hlídaných príkazoch zrušte prepínač daemona a prácu na pozadí nechajte dozorcovi. Obalové skripty, ktoré sa vrátia skôr, než tunel existuje, spôsobujú rovnaký zmätok.

Proces, ktorý sa odpojí od seba, je neviditeľný pre všetko, čo ho malo strážiť.

Relácia sa skončí a odnesie tunel so sebou

Relácia pracovnej plochy vlastní klienta, ktorého spustí. Ukončite prihlásenie a zbernica relácie zmizne, odnesie tunel so sebou, čo vysvetľuje, prečo pripojenie grafického klienta často padne, keď sa zatvorí posledné okno. Servery by mali používať systémovú jednotku alebo profil NetworkManager, ktorý sa zdvihne sám. Používateľská jednotka má zmysel len vtedy, keď má tunel skončiť s prihlásením, preto ju pripnite k cieľu grafickej relácie a napíšte to do jej opisu.

Používateľ služby je druhá polovica toho istého problému. Kľúč, ktorý vlastní root s režimom 0600, je pre jednotku bežiacu pod iným kontom nečitateľný, nech sudo vo vašom shelli dosiahlo čokoľvek.

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

Zoraďte závislé až potom, čo adresa existuje

Keď sa démon naviaže na adresu tunela, ktorá ešte nie je vytvorená, skončí s Cannot assign requested address. Opravou je výslovné zoradenie, nie slučka opakovaných pokusov.

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

After= zoradí úlohy, zatiaľ čo Requires= na jednotke zariadenia viaže závislý proces na existenciu rozhrania, čo je silnejšie než čakať len na sieťový cieľ. Po úprave znova načítajte správcu a reštartujte závislú službu, potom si prečítajte jej journal, namiesto toho, aby ste predpokladali, že poradie zabralo. Posielajte výstup klienta do journalu cez StandardOutput=journal alebo voľbu logovania, pretože hlídaný klient, ktorý píše do súboru, ktorý nikto neotvorí, vyzerá rovnako ako ten, ktorý sa nikdy nespustil.

Potom raz reštartujte a potvrďte, že jednotka je aktívna po tom, čo sa objaví zariadenie tunela. Oprava overená iba pomocou systemctl start neotestovala poradie pri štarte, ktoré mala opraviť.

Súvisiace články