systemd peatab VPN-teenuse: sobitage Type= kliendiga

Algatamise ajal käivituv VPN-ühik muutub passiivseks, kui Type= ei vasta kliendi elueale. Sobitage tüüp, parandage omand ja järjestage teenus tunnelist hiljemaks.

Ühikud võivad tunduda korrektsed, systemctl start võib teatada õnnestumisest ja kümme sekundit hiljem istub teenus passiivsena. Või taaskäivitub see iga poole minuti tagant, kuni käivituspiirang selle peatab. Kumbki käitumine ei ole võrgu tõrge: ühik kirjeldab protsessi eluiga, mis ei vasta sellele, mida klient tegelikult teeb. Klient võib forkida ja väljuda või seansi seadistada ja kohe väljuda.

Miks muutub ühik pärast edukat käivitust sekunditega passiivseks

systemd tuletab oleku protsessist, mille ta käivitas, seega Type= on väide selle protsessi kohta, mitte dokumentatsioon. Type=simple korral loetakse ühik aktiivseks seni, kuni käsk jookseb, ja muutub passiivseks, kui see naaseb. Klient, mis annab ühenduse abiprogrammile üle ja väljub, näeb seetõttu välja nagu krahh, isegi kui tunnel töötab. Seejärel näitab žurnaal käivitus-peatumise mustrit, mida loetakse nagu rikkis binaarfaili.

Lugege ühiku tüüpi kliendi käitumise kõrval enne, kui võrguseadistust puutute.

Valige tüüp, mis kliendiga sobib

Kaks mustrit katavad enamiku tarnijate CLI-dest: käsk, mis seadistab seansi ja väljub, ning käsk, mis forkib enne naasmist abiprogrammi. Kumbki nõuab erinevat ühiku kuju.

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

oneshot koos RemainAfterExit=true hoiab ühiku aktiivsena ka pärast käsu naasmist, mis sobib seadista-ja-välju mustriga, ning peatuskäsk annab teenusele puhta sulgemise. Forkiv klient säilitab sama kuju, kuid vajab Type=forking, et systemd järgiks lapsprotsessi. Seadke Restart=on-failure, RestartSec=30 ja lõplik StartLimitBurst, et teenusepakkuja katkestus ei muutuks taaskäivituste tsükliks, mis vea matab.

Ärge kunagi laske järelevalvataval kliendil deemonistuda

Väljaspool systemd olevad järelevalvajad põrkuvad sama seinaga. runit-skript, mis käivitab deemonistunud kliendi, naaseb kohe järelevalvaja juurde, kes loeb naasmist krahhiks ja käivitab veel ühe koopia. Iga järelevalvaja eeldab, et omab esiplaanil olevat protsessi, nii nagu sshd -D jääb ette. Eemaldage järelevalvatavate käskude puhul deemonilip ja jätke taustatöö järelevalvajale. Ümbrisskriptid, mis naasevad enne, kui tunnel olemas on, tekitavad sama segaduse.

Protsess, mis endast lahti haakub, on nähtamatu kõigele, mis pidi seda jälgima.

Seanss lõpeb ja viib tunneli endaga kaasa

Töölaua seanss omab klienti, mille ta käivitab. Lõpetage sisselogimine ja seansi buss kaob, võttes tunneli kaasa, mis selgitab, miks graafilise kliendi ühendus sageli katkeb, kui viimane aken sulgub. Serverid peaksid kasutama süsteemiühikut või NetworkManageri profiili, mis tõuseb ise. Kasutajaühik on mõttekas ainult siis, kui tunnel peab lõppema koos sisselogimisega, seega siduge see graafilise seansi sihtmärgiga ja kirjutage see kirjeldusse.

Teenuse kasutaja on sama probleemi teine pool. Rootile kuuluv võti režiimiga 0600 on teise kontoga jooksva ühiku jaoks loetamatu, ükskõik mida sudo teie kestas saavutas.

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

Järjestage sõltuvad teenused pärast aadressi olemasolu

Kui deemon seob end tunneli aadressiga, mida veel loodud ei ole, väljub see teatega Cannot assign requested address. Parandus on selgesõnaline järjestamine, mitte korduskatse tsükkel.

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

After= järjestab tööd, samas kui seadmeühiku Requires= seob sõltuva teenuse liidese olemasoluga, mis on tugevam kui ainult võrgusihtmärgi ootamine. Pärast muutmist laadige haldur uuesti ja taaskäivitage sõltuv teenus, seejärel lugege selle žurnaali, selle asemel et eeldada, et järjekord mõjus. Saatke kliendi väljund žurnaali StandardOutput=journal või logimisvalikuga, sest järelevalvatav klient, mis kirjutab faili, mida keegi ei ava, näeb välja täpselt nagu see, mis ei käivitunud kunagi.

Seejärel taaskäivitage korra ja kinnitage, et ühik on aktiivne pärast tunneli seadme ilmumist. Parandus, mida kontrolliti ainult systemctl start abil, ei ole testinud alglaadimise järjekorda, mida see pidi parandama.

Seotud artiklid