systemd stopper VPN-tjenesten: tilpass Type= til klienten

Enheter kan se riktige ut, systemctl start kan rapportere suksess, og ti sekunder senere står tjenesten inaktiv. Eller den starter på nytt hvert halvminutt til startgrensen stopper den. Ingen av atferdene er en nettverksfeil: enheten beskriver en prosesslevetid som ikke passer til det klienten faktisk gjør. Klienten kan forke og avslutte, eller konfigurere økten og avslutte med en gang.

Hvorfor enheten blir inaktiv sekunder etter en vellykket start

systemd utleder tilstanden fra prosessen den startet, så Type= er en påstand om den prosessen, ikke dokumentasjon. Med Type=simple regnes enheten som aktiv mens kommandoen kjører, og blir inaktiv når den kommer tilbake. En klient som overlater forbindelsen til en hjelper og avslutter, ser derfor ut som et krasj, selv når tunnelen er oppe. Journalen viser da et start-stopp-mønster som leses som en feilende binærfil.

Les enhetstypen ved siden av klientens atferd før du rører nettverkskonfigurasjonen.

Velg typen som passer til klienten

To mønstre dekker de fleste leverandør-CLI-er: en kommando som konfigurerer en økt og avslutter, og en kommando som forker en hjelper før den kommer tilbake. Hver av dem krever en annen enhetsform.

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

oneshot med RemainAfterExit=true holder enheten aktiv etter at kommandoen kommer tilbake, noe som passer til konfigurer-og-avslutt-mønsteret, og stoppkommandoen gir tjenesten en ren nedstenging. 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 omstartsløkke som begraver feilen.

La aldri en overvåket klient dæmonisere

Overvåkere utenfor systemd treffer samme vegg. Et runit-kjøreskript som starter en dæmonisert klient, kommer straks tilbake til overvåkeren, som leser returen som et krasj og starter enda en kopi. Enhver overvåker forventer å eie forgrunnsprosessen, slik sshd -D blir stående foran. Fjern dæmonflagget for overvåkede kommandoer og la overvåkeren gjøre bakgrunnsjobben. Innpakningsskript som kommer tilbake før tunnelen finnes, gir samme forvirring.

En prosess som løsriver 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, noe som forklarer hvorfor en grafisk klients tilkobling ofte faller når det siste vinduet lukkes. Tjenere bør bruke en systemenhet eller en NetworkManager-profil som kommer opp av seg selv. En brukerenhet gir bare mening når tunnelen skal slutte med innloggingen, så bind den til den grafiske øktens mål og si det i beskrivelsen.

Tjenestebrukeren er den andre halvdelen av samme problem. En nøkkel som eies av root med modus 0600 er uleselig for en enhet som kjører som en annen konto, uansett hva sudo oppnådde 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

Sett avhengige etter at adressen finnes

Når en dæmon binder til en tunneladresse som ikke er opprettet ennå, avslutter den med Cannot assign requested address. Rettelsen er eksplisitt rekkefølge, ikke en forsøksløkke.

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

After= ordner jobbene, mens Requires= på enhetsenheten binder den avhengige til grensesnittets eksistens, som er sterkere enn å vente bare på nettverksmålet. Last inn administratoren på nytt etter redigering og start den avhengige tjenesten på nytt, og les deretter journalen i stedet for å anta at rekkefølgen virket. Send klientens utdata 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 deretter på nytt én gang og bekreft at enheten er aktiv etter at tunneleenheten dukker opp. En rettelse som bare er verifisert med systemctl start, har ikke testet oppstartsrekkefølgen den skulle rette.