systemd aptur VPN pakalpojumu: saskaņojiet Type= ar klientu

Sāknēšanas laikā startējošā VPN vienība kļūst neaktīva, ja Type= neatbilst klienta dzīves ilgumam. Saskaņojiet tipu, izlabojiet īpašumtiesības un sakārtojiet pakalpojumu pēc tuneļa.

Vienības var izskatīties pareizi, systemctl start var ziņot par panākumiem, un desmit sekundes vēlāk pakalpojums stāv neaktīvs. Vai arī tas restartējas ik pēc pusminūtes, līdz startēšanas limits to aptur. Neviena no uzvedībām nav tīkla kļūme: vienība apraksta procesa dzīves ilgumu, kas neatbilst tam, ko klients patiešām dara. Klients var atdalīties un iziet, vai konfigurēt sesiju un iziet uzreiz.

Kāpēc vienība kļūst neaktīva dažas sekundes pēc veiksmīgas startēšanas

systemd stāvokli secina no procesa, ko tas pats startēja, tāpēc Type= ir apgalvojums par šo procesu, nevis dokumentācija. Ar Type=simple vienība tiek uzskatīta par aktīvu, kamēr komanda darbojas, un kļūst neaktīva, kad tā atgriežas. Tāpēc klients, kas nodod savienojumu palīgam un iziet, izskatās pēc avārijas, pat ja tunelis darbojas. Tad žurnāls rāda startēšanas un apstāšanās modeli, kas lasās kā bojāts binārais fails.

Izlasiet vienības tipu līdzās klienta uzvedībai, pirms aiztiecat tīkla konfigurāciju.

Izvēlieties tipu, kas atbilst klientam

Divi modeļi aptver lielāko daļu piegādātāju CLI: komanda, kas konfigurē sesiju un iziet, un komanda, kas pirms atgriešanās atdala palīgu. Katram vajadzīga cita vienības forma.

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

oneshot kopā ar RemainAfterExit=true uztur vienību aktīvu pēc komandas atgriešanās, kas atbilst konfigurē-un-izej modelim, un apstāšanās komanda dod pakalpojumam tīru izslēgšanu. Atdalošais klients saglabā to pašu formu, bet tam vajag Type=forking, lai systemd sekotu bērnam. Iestatiet Restart=on-failure, RestartSec=30 un galīgu StartLimitBurst, lai piegādātāja pārtraukums nepārvērstos restartu cilpā, kas apglabā kļūdu.

Nekad neļaujiet uzraudzītam klientam kļūt par dēmonu

Uzraugi ārpus systemd atduras pret to pašu sienu. runit palaišanas skripts, kas startē dēmonizētu klientu, uzreiz atgriežas pie uzrauga, un tas atgriešanos nolasa kā avāriju un startē vēl vienu kopiju. Katrs uzraugs sagaida, ka tam pieder priekšplāna process, kā sshd -D paliek priekšā. Noņemiet dēmona karogu uzraudzītajām komandām un ļaujiet uzraugam veikt fona darbu. Aptinējumu skripti, kas atgriežas pirms tuneļa eksistēšanas, rada to pašu apjukumu.

Process, kas atdalās no sevis, ir neredzams visam, kam tas bija jāuzrauga.

Sesija beidzas un paņem tuneli līdzi

Darbvirsmas sesijai pieder klients, ko tā startē. Pabeidziet pieteikšanos, un sesijas kopne pazūd, paņemot tuneli līdzi, kas izskaidro, kāpēc grafiskā klienta savienojums bieži pārtrūkst, kad aizveras pēdējais logs. Serveriem vajadzētu izmantot sistēmas vienību vai NetworkManager profilu, kas paceļas pats. Lietotāja vienība ir jēgpilna tikai tad, kad tunelim jābeidzas kopā ar pieteikšanos, tāpēc piesaistiet to grafiskās sesijas mērķim un norādiet to aprakstā.

Pakalpojuma lietotājs ir otra tās pašas problēmas puse. root piederoša atslēga ar režīmu 0600 nav nolasāma vienībai, kas darbojas ar citu kontu, lai ko sudo būtu panācis jūsu čaulā.

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

Sakārtojiet atkarīgos pēc tam, kad adrese ir radusies

Kad dēmons piesaistās tuneļa adresei, kas vēl nav izveidota, tas iziet ar Cannot assign requested address. Labojums ir skaidra secība, nevis atkārtojumu cilpa.

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

After= sakārto darbus, bet Requires= ierīces vienībā piesaista atkarīgo saskarnes eksistencei, kas ir spēcīgāk nekā gaidīt tikai tīkla mērķi. Pēc rediģēšanas pārlādējiet pārvaldnieku un restartējiet atkarīgo pakalpojumu, tad izlasiet tā žurnālu, nevis pieņemiet, ka secība ir nostrādājusi. Sūtiet klienta izvadi uz žurnālu ar StandardOutput=journal vai žurnāla opciju, jo uzraudzīts klients, kas raksta failā, ko neviens neatver, izskatās tieši tāpat kā tāds, kas nekad nav startējis.

Pēc tam vienreiz restartējiet un apstipriniet, ka vienība ir aktīva pēc tam, kad parādās tuneļa ierīce. Labojums, kas pārbaudīts tikai ar systemctl start, nav pārbaudījis startēšanas secību, kas tam bija jāizlabo.

Saistītie raksti