systemd stoppar VPN-tenesta: tilpass Type= til klienten

Einingar kan sjå riktige ut, systemctl start kan melde suksess, og ti sekund seinare står tenesta inaktiv. Eller ho startar på nytt kvart halvminutt til startgrensa stoppar ho. Ingen av åtferdene er ein nettverksfeil: eininga skildrar ei prosesslevetid som ikkje passar til det klienten faktisk gjer. Klienten kan forke og avslutte, eller konfigurere økta og avslutte med ein gong.

Kvifor eininga blir inaktiv sekund etter ein vellukka start

systemd leier tilstanden ut frå prosessen han starta, så Type= er ein påstand om den prosessen, ikkje dokumentasjon. Med Type=simple blir eininga rekna som aktiv medan kommandoen køyrer, og blir inaktiv når han kjem tilbake. Ein klient som overlèt sambandet til ein hjelpar og avsluttar, ser derfor ut som eit krasj, sjølv når tunnelen er oppe. Journalen viser då eit start-stopp-mønster som blir lese som ei feilande binærfil.

Les einingstypen ved sida av åtferda til klienten før du rører nettverkskonfigurasjonen.

Vel typen som passar til klienten

To mønster dekkjer dei fleste leverandør-CLI-ar: ein kommando som konfigurerer ei økt og avsluttar, og ein kommando som forkar ein hjelpar før han kjem tilbake. Kvar av dei krev ei anna einingsform.

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

oneshot med RemainAfterExit=true held eininga aktiv etter at kommandoen kjem tilbake, noko som passar til konfigurer-og-avslutt-mønsteret, og stoppkommandoen gjev tenesta ei rein nedstenging. Ein forkande klient held same form, men treng Type=forking for at systemd skal følgje barnet. Set Restart=on-failure, RestartSec=30 og ein endeleg StartLimitBurst, slik at eit avbrot hos leverandøren ikkje blir ei omstartssløyfe som grev ned feilen.

Lat aldri ein overvaka klient dæmonisere

Overvakarar utanfor systemd treffer same veggen. Eit runit-køyreskript som startar ein dæmonisert klient, kjem straks tilbake til overvakaren, som les returen som eit krasj og startar endå ei kopi. Kvar overvakar ventar å eige forgrunnsprosessen, slik sshd -D blir ståande framme. Fjern dæmonflagget for overvaka kommandoar og lat overvakaren gjere bakgrunnsjobben. Innpakningsskript som kjem tilbake før tunnelen finst, gjev same forvirringa.

Ein prosess som løyser seg sjølv frå, er usynleg for alt som skulle halde auga med han.

Økta blir avslutta og tek tunnelen med seg

Ei skrivebordsøkt eig klienten ho startar. Avslutt innlogginga, og øktbussen forsvinn og tek tunnelen med, noko som forklarar kvifor tilknytinga til ein grafisk klient ofte fell når det siste vindauget blir lukka. Tenarar bør bruke ei systemeining eller ein NetworkManager-profil som kjem opp av seg sjølv. Ei brukareining gjev berre meining når tunnelen skal slutte med innlogginga, så bind ho til målet for den grafiske økta og skriv det i skildringa.

Tenestebrukaren er den andre halvdelen av same problemet. Ein nøkkel som er eigd av root med modus 0600 er uleseleg for ei eining som køyrer som ein annan konto, uansett kva sudo oppnådde i skalet ditt.

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

Set avhengige etter at adressa finst

Når ein dæmon bind til ei tunneladresse som ikkje er oppretta enno, avsluttar han med Cannot assign requested address. Rettinga er eksplisitt rekkjefølgje, ikkje ei freistingssløyfe.

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

After= ordnar jobbane, medan Requires= på einingseininga bind den avhengige til at grensesnittet finst, som er sterkare enn å vente berre på nettverksmålet. Last inn administratoren på nytt etter redigering og start den avhengige tenesta på nytt, og les deretter journalen i staden for å tru at rekkjefølgja verka. Send utdata frå klienten til journalen med StandardOutput=journal eller eit loggalternativ, fordi ein overvaka klient som skriv til ei fil ingen opnar, ser identisk ut med ein som aldri starta.

Start deretter på nytt éin gong og stadfest at eininga er aktiv etter at tunneleininga dukkar opp. Ei retting som berre er stadfesta med systemctl start, har ikkje testa oppstartsrekkjefølgja ho skulle rette.