systemd haltigas la VPN-servon: agordu Type= al la kliento

VPN-unuo ĉe lanĉo fariĝas neaktiva kiam Type= ne kongruas kun la vivo de la kliento. Agordu la tipon, riparu posedon kaj ordigu la servon post la tunelo.

Unuoj povas ŝajni ĝustaj, systemctl start povas raporti sukceson, kaj dek sekundojn poste la servo sidas neaktiva. Aŭ ĝi restartiĝas ĉiun duonan minuton ĝis la lanĉa limo haltigas ĝin. Neniu el la du kondutoj estas reta difekto: la unuo priskribas procezan vivon, kiu ne kongruas kun tio, kion la kliento efektive faras. La kliento povas forki kaj eliri, aŭ agordi la seancon kaj tuj eliri.

Kial la unuo fariĝas neaktiva sekundojn post sukcesa lanĉo

systemd derivas la staton el la procezo, kiun ĝi lanĉis, do Type= estas aserto pri tiu procezo, ne dokumentado. Kun Type=simple la unuo validas kiel aktiva dum la komando ruliĝas kaj fariĝas neaktiva kiam ĝi revenas. Kliento, kiu transdonas la konekton al helpanto kaj eliras, do aspektas kiel kolapso, eĉ kiam la tunelo estas supre. La ĵurnalo tiam montras lanĉo-haltan ŝablonon, kiu legeblas kiel difekta duuma dosiero.

Legu la tipon de la unuo apud la konduto de la kliento antaŭ ol tuŝi la retan agordon.

Elektu la tipon, kiu kongruas kun la kliento

Du ŝablonoj kovras plej multajn vendistajn CLI-ojn: komando, kiu agordas seancon kaj eliras, kaj komando, kiu forkas helpanton antaŭ ol reveni. Ĉiu bezonas alian unuan formon.

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

oneshot kun RemainAfterExit=true tenas la unuon aktiva post kiam la komando revenas, kio kongruas kun la ŝablono agordi-kaj-eliri, kaj la halta komando donas al la servo puran ĉesigon. Forkanta kliento konservas la saman formon sed bezonas Type=forking, por ke systemd sekvu la infanon. Agordu Restart=on-failure, RestartSec=30 kaj finian StartLimitBurst, por ke paneo de provizanto ne fariĝu restarta buklo, kiu entombigas la eraron.

Neniam lasu superrigardatan klienton demoniĝi

Superrigardantoj ekster systemd trafas la saman muron. runit-skripto, kiu lanĉas demonigitan klienton, tuj revenas al la superrigardanto, kiu legas la revenon kiel kolapson kaj lanĉas alian kopion. Ĉiu superrigardanto atendas posedi la unuan procezon, same kiel sshd -D restas antaŭe. Forigu la demonan flagon por superrigardataj komandoj kaj lasu al la superrigardanto la fonan laboron. Ĉirkaŭaj skriptoj, kiuj revenas antaŭ ol la tunelo ekzistas, kaŭzas la saman konfuzon.

Procezo, kiu apartiĝas de si mem, estas nevidebla por ĉio, kio devis observi ĝin.

La seanco finiĝas kaj forportas la tunelon

Labortabla seanco posedas la klienton, kiun ĝi lanĉas. Finu la ensaluton kaj la seanca buso malaperas, forportante la tunelon, kio klarigas, kial la konekto de grafika kliento ofte falas kiam fermiĝas la lasta fenestro. Serviloj uzu sistem-unuon aŭ NetworkManager-profilon, kiu leviĝas per si mem. Uzanta unuo havas sencon nur kiam la tunelo devas finiĝi kun la ensaluto, do ligu ĝin al la celo de la grafika seanco kaj diru tion en ĝia priskribo.

La serva uzanto estas la alia duono de la sama problemo. Ŝlosilo posedata de root kun reĝimo 0600 estas nelegebla por unuo, kiu ruliĝas sub alia konto, kion ajn sudo atingis en via ŝelo.

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

Ordigi la dependulojn post kiam la adreso ekzistas

Kiam demono ligiĝas al tunela adreso, kiu ankoraŭ ne kreiĝis, ĝi eliras kun Cannot assign requested address. La ripariĝo estas eksplicita ordigo, ne buklo de reprovado.

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

After= ordigas la taskojn, dum Requires= ĉe la aparat-unuo ligas la dependulon al la ekzisto de la interfaco, kio estas pli forta ol atendi nur la retan celon. Reŝargu la administrilon post redaktado kaj restartigu la dependan servon, poste legu ĝian ĵurnalon anstataŭ supozi, ke la ordo efikis. Sendu la eligon de la kliento al la ĵurnalo per StandardOutput=journal aŭ loga opcio, ĉar superrigardata kliento, kiu skribas al dosiero, kiun neniu malfermas, aspektas idente al unu, kiu neniam lanĉiĝis.

Poste restartigu unufoje kaj konfirmu, ke la unuo estas aktiva post kiam la tunela aparato aperas. Riparo kontrolita nur per systemctl start ne testis la lanĉan ordon, kiun ĝi devis ripari.

Rilataj artikoloj