systemd stanser VPN-tjenesten: tilpass Type= til klienten

Unitene kan se riktige ut, systemctl start kan rapportere at alt gikk bra, og ti sekunder senere står tjenesten inaktiv. Eller den restarter hvert halve minutt helt til startgrensen stopper den. Ingen av disse oppførslene er en nettverksfeil: uniten beskriver en prosesslevetid som ikke samsvarer med det klienten faktisk gjør. Klienten kan forke og avslutte, eller sette opp økten og avslutte umiddelbart.

Hvorfor uniten går inaktiv få sekunder etter en vellykket start

systemd utleder tilstanden fra prosessen den startet, så Type= er en påstand om den prosessen og ikke dokumentasjon. Med Type=simple regnes uniten som aktiv så lenge kommandoen kjører, og går inaktiv når den returnerer. En klient som gir fra seg tilkoblingen til en hjelper og avslutter, fremstår derfor som en krasj, selv når tunnelen er oppe. Journalen viser da et start-stopp-mønster som leses som en defekt binær.

Les unittypen sammen med klientens oppførsel før du tar i nettverkskonfigurasjonen.

Velg den typen som samsvarer med klienten

To mønstre dekker de fleste leverandør-CLI-er: en kommando som setter opp en økt og avslutter, og en kommando som forker en hjelper før den returnerer. Hver av dem krever en annen unitform.

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

oneshot sammen med RemainAfterExit=true holder uniten aktiv etter at kommandoen returnerer, noe som samsvarer med mønsteret sett opp og avslutt, og stoppkommandoen gir tjenesten en ren avslutning. En forkende klient beholder samme form, men trenger Type=forking for at systemd skal følge barnet. Sett Restart=on-failure, RestartSec=30 og en endelig StartLimitBurst, slik at et avbrudd hos leverandøren ikke blir en restartsløyfe som begraver feilen.

La aldri en overvåket klient daemonisere

Overvåkere utenfor systemd møter samme veggen. Et runit-kjøreskript som starter en daemonisert klient, returnerer straks til overvåkeren, som leser returen som en krasj og starter nok en kopi. Enhver overvåker forventer å eie forgrunnsprosessen, slik sshd -D blir stående foran. Fjern daemonflagget for overvåkede kommandoer og la overvåkeren ta seg av bakgrunnen. Innpakningsskript som returnerer før tunnelen finnes, gir samme forvirringen.

En prosess som kobler seg løs fra seg selv, er usynlig for alt som skulle holde øye med den.

Økten avsluttes og tar tunnelen med seg

En skrivebordsøkt eier klienten den starter. Avslutt innloggingen, og øktbussen forsvinner og tar tunnelen med seg, noe som forklarer hvorfor tilkoblingen til en grafisk klient ofte faller når det siste vinduet lukkes. Tjenere bør bruke en systemunit eller en NetworkManager-profil som kommer opp av seg selv. En brukerunit er bare fornuftig når tunnelen skal avsluttes sammen med innloggingen, så bind den til målet for den grafiske økten og si det i beskrivelsen.

Tjenestebrukeren er den andre halvdelen av det samme problemet. En nøkkel som eies av root med modus 0600 er uleselig for en unit som kjører som en annen konto, uansett hva sudo fikk til i skallet ditt.

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

Ordne avhengige etter at adressen finnes

Når en daemon binder seg til en tunneladresse som ennå ikke er opprettet, avslutter den med Cannot assign requested address. Rettelsen er eksplisitt rekkefølge, ikke en løkke med nye forsøk.

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

After= ordner jobbene, mens Requires= på enhetsuniten binder den avhengige til at grensesnittet finnes, noe som er sterkere enn å vente bare på nettverksmålet. Last inn manageren på nytt etter redigering og start den avhengige tjenesten på nytt, og les deretter journalen i stedet for å anta at rekkefølgen virket. Send utdata fra klienten til journalen med StandardOutput=journal eller et loggalternativ, fordi en overvåket klient som skriver til en fil ingen åpner, ser identisk ut med en som aldri startet.

Start så på nytt én gang og bekreft at uniten er aktiv etter at tunneenheten dukker opp. En rettelse som bare er verifisert med systemctl start, har ikke testet oppstartsrekkefølgen den skulle rette.