systemd stopper VPN-tjenesten: tilpas Type= til klienten

Units kan se korrekte ud, systemctl start kan rapportere succes, og ti sekunder senere står tjenesten inaktiv. Eller den genstarter hvert halve minut, indtil startgrænsen stopper den. Ingen af adfærdene er en netværksfejl: uniten beskriver en proceslevetid, der ikke passer til det, klienten faktisk gør. Klienten kan forke og afslutte, eller konfigurere sessionen og afslutte med det samme.

Hvorfor uniten bliver inaktiv få sekunder efter en vellykket start

systemd udleder tilstanden fra den proces, den startede, så Type= er en påstand om den proces, ikke dokumentation. Med Type=simple tæller uniten som aktiv, mens kommandoen kører, og bliver inaktiv, når den vender tilbage. En klient, der overlader forbindelsen til en hjælper og afslutter, ser derfor ud som et nedbrud, selv når tunnelen er oppe. Journalen viser derefter et start-stop-mønster, der læses som en fejlende binær.

Læs unitens type ved siden af klientens adfærd, før du rører netværkskonfigurationen.

Vælg den type, der passer til klienten

To mønstre dækker de fleste leverandør-CLI'er: en kommando, der konfigurerer en session og afslutter, og en kommando, der forker en hjælper, før den vender tilbage. Hver især kræver de en anden unitform.

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

oneshot med RemainAfterExit=true holder uniten aktiv, efter kommandoen vender tilbage, hvilket passer til konfigurer-og-afslut-mønstret, og stopkommandoen giver tjenesten en ren nedlukning. En forkende klient beholder samme form, men kræver Type=forking, så systemd følger barnet. Sæt Restart=on-failure, RestartSec=30 og et endeligt StartLimitBurst, så en udbyderafbrydelse ikke kan blive til en genstartsloop, der begraver fejlen.

Lad aldrig en overvåget klient dæmonisere

Supervisorer uden for systemd rammer den samme mur. Et runit-run-script, der starter en dæmoniseret klient, vender straks tilbage til supervisoren, som læser returen som et nedbrud og starter endnu en kopi. Enhver supervisor forventer at eje forgrundsprocessen, sådan som sshd -D bliver foran. Fjern dæmonflaget for overvågede kommandoer, og lad supervisoren klare baggrunden. Indpakningsscripts, der vender tilbage, før tunnelen findes, giver samme forvirring.

En proces, der løsriver sig selv, er usynlig for alt, der skulle holde øje med den.

Sessionen slutter og tager tunnelen med sig

En skrivebordssession ejer den klient, den starter. Afslut login, og sessionsbussen forsvinder og tager tunnelen med, hvilket forklarer, hvorfor en grafisk klients forbindelse ofte falder, når det sidste vindue lukkes. Servere bør bruge en system-unit eller en NetworkManager-profil, der kommer op af sig selv. En bruger-unit giver kun mening, når tunnelen skal slutte med login, så bind den til den grafiske sessions target, og skriv det i beskrivelsen.

Tjenestebrugeren er den anden halvdel af samme problem. En nøgle, der ejes af root med tilstand 0600, er ulæselig for en unit, der kører som en anden konto, uanset hvad sudo opnåede i din shell.

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

Sæt afhængige efter adressen findes

Når en dæmon binder til en tunneladresse, der endnu ikke er oprettet, afslutter den med Cannot assign requested address. Rettelsen er eksplicit rækkefølge, ikke en forsøgsloop.

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

After= ordner jobbene, mens Requires= på enhedsuniten binder den afhængige til grænsefladens eksistens, hvilket er stærkere end at vente på netværks-targetet alene. Genindlæs manageren efter redigering, og genstart den afhængige tjeneste, og læs derefter dens journal i stedet for at antage, at rækkefølgen virkede. Send klientens output til journalen med StandardOutput=journal eller en logindstilling, fordi en overvåget klient, der skriver til en fil, ingen åbner, ser identisk ud med en, der aldrig startede.

Genstart derefter én gang, og bekræft, at uniten er aktiv, efter tunneleenheden dukker op. En rettelse, der kun er verificeret med systemctl start, har ikke testet den opstartsrækkefølge, den skulle rette.