hinihinto ng systemd ang serbisyo ng VPN: itugma ang Type= sa kliyente

Maaaring mukhang tama ang mga yunit, maaaring mag-ulat ng tagumpay ang systemctl start, at makalipas ang sampung segundo ay hindi aktibo ang serbisyo. O nagre-restart ito tuwing kalahating minuto hanggang pigilan ito ng limitasyon sa pagsisimula. Wala sa dalawang pag-uugali ang sira ng network: inilalarawan ng yunit ang haba ng buhay ng proseso na hindi tugma sa ginagawa talaga ng kliyente. Maaaring mag-fork at lumabas ang kliyente, o i-configure ang sesyon at lumabas agad.

Bakit nagiging hindi aktibo ang yunit ilang segundo pagkatapos ng matagumpay na pagsisimula

Hinihinuha ng systemd ang kalagayan mula sa prosesong sinimulan nito, kaya ang Type= ay isang pahayag tungkol sa prosesong iyon, hindi dokumentasyon. Sa Type=simple binibilang ang yunit na aktibo habang tumatakbo ang utos at nagiging hindi aktibo kapag bumalik ito. Kaya ang kliyenteng nagbibigay ng koneksyon sa isang katulong at lumabas ay mukhang pag-crash, kahit nakaangat ang tunel. Pagkatapos ay nagpapakita ang journal ng pattern ng pagsisimula at paghinto na binabasa na parang sira ang binary.

Basahin ang uri ng yunit sa tabi ng pag-uugali ng kliyente bago hipuin ang configuration ng network.

Piliin ang uri na tumutugma sa kliyente

Dalawang pattern ang sumasaklaw sa karamihan ng CLI ng vendor: isang utos na nag-configure ng sesyon at lumalabas, at isang utos na nag-fork ng katulong bago bumalik. Kailangan ng bawat isa ng ibang hugis ng yunit.

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

oneshot kasama ng RemainAfterExit=true ay nagpapanatili sa yunit na aktibo pagkatapos bumalik ang utos, na tumutugma sa pattern na i-configure at lumabas, at binibigyan ng utos ng paghinto ang serbisyo ng malinis na pagsasara. Ang kliyenteng nag-fork ay nagpapanatili ng parehong hugis ngunit kailangan ng Type=forking upang sundan ng systemd ang anak. Itakda ang Restart=on-failure, RestartSec=30 at isang may hangganang StartLimitBurst, upang ang pagkaantala ng provider ay hindi maging loop ng pag-restart na naglilibing sa error.

Huwag kailanman hayaang maging daemon ang isang pinangangasiwaang kliyente

Ang mga superbisor sa labas ng systemd ay bumabangga sa parehong pader. Ang runit run script na naglulunsad ng daemonized na kliyente ay agad na bumabalik sa superbisor, na nagbabasa ng pagbabalik na iyon bilang pag-crash at naglulunsad ng isa pang kopya. Inaasahan ng bawat superbisor na pagmamay-ari nito ang proseso sa harapan, tulad ng sshd -D na nananatili sa unahan. Alisin ang daemon flag para sa mga pinangangasiwaang utos at hayaang ang superbisor ang gumawa ng gawain sa likuran. Ang mga wrapper script na bumabalik bago umiral ang tunel ay nagdudulot ng parehong kalituhan.

Ang prosesong humihiwalay sa sarili nito ay hindi nakikita ng lahat ng dapat na nagmamatyag dito.

Nagtatapos ang sesyon at dinadala ang tunel

Pagmamay-ari ng desktop session ang kliyenteng inilulunsad nito. Tapusin ang pag-log in at mawawala ang session bus, dala ang tunel, na nagpapaliwanag kung bakit madalas bumagsak ang koneksyon ng graphical na kliyente kapag nagsasara ang huling bintana. Dapat gumamit ang mga server ng system unit o profile ng NetworkManager na kusang bumabangon. May kabuluhan lamang ang user unit kapag ang tunel ay dapat magtapos kasama ng pag-log in, kaya iugnay ito sa target ng graphical session at sabihin iyon sa paglalarawan nito.

Ang user ng serbisyo ay ang kabilang kalahati ng parehong problema. Ang susi na pagmamay-ari ng root na may mode 0600 ay hindi mababasa ng yunit na tumatakbo sa ibang account, anuman ang nagawa ng sudo sa shell mo.

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

Ihanay ang mga nakadepende kapag umiral na ang address

Kapag nagbigkis ang daemon sa address ng tunel na hindi pa nagagawa, lumalabas ito nang may Cannot assign requested address. Ang pag-aayos ay tahasang paghahanay, hindi loop ng muling pagsubok.

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

After= ay naghahanay ng mga trabaho, habang ang Requires= sa unit ng device ay nag-uugnay sa nakadepende sa pag-iral ng interface, na mas malakas kaysa maghintay lamang sa target ng network. I-reload ang manager pagkatapos mag-edit at i-restart ang nakadependeng serbisyo, pagkatapos basahin ang journal nito sa halip na ipagpalagay na gumana ang pagkakasunod-sunod. Ipadala ang output ng kliyente sa journal gamit ang StandardOutput=journal o isang opsyon sa log, dahil ang pinangangasiwaang kliyente na nagsusulat sa file na walang nagbubukas ay mukhang kapareho ng isang hindi kailanman nagsimula.

Pagkatapos ay i-reboot nang isang beses at kumpirmahin na aktibo ang yunit kapag lumitaw ang device ng tunel. Ang pag-aayos na na-verify lamang sa systemctl start ay hindi nasubukan ang pagkakasunod-sunod ng boot na dapat nitong ayusin.