systemd menghentikan perkhidmatan VPN: padankan Type= dengan klien

Unit boleh kelihatan betul, systemctl start boleh melaporkan kejayaan, dan sepuluh saat kemudian perkhidmatan duduk tidak aktif. Atau ia dimulakan semula setiap setengah minit sehingga had permulaan menghentikannya. Kedua-dua tingkah laku itu bukan kerosakan rangkaian: unit menerangkan jangka hayat proses yang tidak sepadan dengan apa yang klien sebenarnya lakukan. Klien mungkin fork dan keluar, atau mengkonfigurasi sesi lalu keluar serta-merta.

Mengapa unit menjadi tidak aktif beberapa saat selepas permulaan yang berjaya

systemd menyimpulkan keadaan daripada proses yang dimulakannya, jadi Type= ialah dakwaan tentang proses itu, bukan dokumentasi. Dengan Type=simple unit dikira aktif semasa arahan berjalan dan menjadi tidak aktif apabila ia kembali. Klien yang menyerahkan sambungan kepada pembantu lalu keluar kelihatan seperti ranap, walaupun terowong berjalan. Jurnal kemudian menunjukkan corak mula dan henti yang dibaca seperti binari yang rosak.

Baca jenis unit di sebelah tingkah laku klien sebelum menyentuh konfigurasi rangkaian.

Pilih jenis yang sepadan dengan klien

Dua corak meliputi kebanyakan CLI vendor: arahan yang mengkonfigurasi sesi lalu keluar, dan arahan yang fork pembantu sebelum kembali. Setiap satu memerlukan bentuk unit yang berbeza.

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

oneshot dengan RemainAfterExit=true mengekalkan unit aktif selepas arahan kembali, yang sepadan dengan corak konfigurasi lalu keluar, dan arahan henti memberikan perkhidmatan penutupan bersih. Klien yang fork mengekalkan bentuk yang sama tetapi memerlukan Type=forking supaya systemd mengikuti anaknya. Tetapkan Restart=on-failure, RestartSec=30 dan StartLimitBurst yang terbatas, supaya gangguan penyedia tidak menjadi gelung mula semula yang menimbus ralat.

Jangan sekali-kali biarkan klien yang diawasi menjadi daemon

Penyelia di luar systemd menempuh dinding yang sama. Skrip larian runit yang memulakan klien yang didaemonkan kembali kepada penyelia serta-merta, yang membaca kepulangan itu sebagai ranap dan memulakan satu lagi salinan. Setiap penyelia menjangka memiliki proses latar depan, seperti sshd -D kekal di hadapan. Buang bendera daemon untuk arahan yang diawasi dan biarkan penyelia mengendalikan latar belakang. Skrip pembalut yang kembali sebelum terowong wujud menyebabkan kekeliruan yang sama.

Proses yang melepaskan dirinya daripada dirinya sendiri tidak kelihatan kepada apa pun yang sepatutnya mengawasinya.

Sesi berakhir dan membawa terowong bersamanya

Sesi desktop memiliki klien yang dimulakannya. Tamatkan log masuk dan bas sesi hilang, membawa terowong bersamanya, yang menjelaskan mengapa sambungan klien grafik sering terputus apabila tetingkap terakhir ditutup. Pelayan harus menggunakan unit sistem atau profil NetworkManager yang naik sendiri. Unit pengguna hanya masuk akal apabila terowong sepatutnya berakhir dengan log masuk, jadi ikatkannya pada sasaran sesi grafik dan nyatakan itu dalam keterangannya.

Pengguna perkhidmatan ialah separuh lagi masalah yang sama. Kunci milik root dengan mod 0600 tidak boleh dibaca oleh unit yang berjalan sebagai akaun lain, apa pun yang dicapai sudo dalam shell anda.

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

Susun dependen selepas alamat wujud

Apabila daemon mengikat kepada alamat terowong yang belum dicipta, ia keluar dengan Cannot assign requested address. Pembaikannya ialah susunan eksplisit, bukan gelung cubaan semula.

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

After= menyusun tugas, manakala Requires= pada unit peranti mengikat dependen kepada kewujudan antara muka, yang lebih kuat daripada hanya menunggu sasaran rangkaian. Muat semula pengurus selepas menyunting dan mulakan semula perkhidmatan dependen, kemudian baca jurnalnya daripada menganggap susunan itu berkesan. Hantar output klien ke jurnal dengan StandardOutput=journal atau pilihan log, kerana klien yang diawasi yang menulis ke fail yang tiada siapa membuka kelihatan sama seperti klien yang tidak pernah bermula.

Kemudian but semula sekali dan sahkan unit aktif selepas peranti terowong muncul. Pembaikan yang disahkan hanya dengan systemctl start belum menguji susunan but yang sepatutnya dibaiki.