systemd menghentikan layanan VPN: cocokkan Type= dengan klien

Unit bisa terlihat benar, systemctl start bisa melaporkan keberhasilan, dan sepuluh detik kemudian layanan duduk tidak aktif. Atau ia memulai ulang setiap setengah menit sampai batas start menghentikannya. Tidak satu pun perilaku itu kesalahan jaringan: unit menjelaskan masa hidup proses yang tidak cocok dengan apa yang benar-benar dilakukan klien. Klien bisa melakukan fork dan keluar, atau mengonfigurasi sesi lalu langsung keluar.

Mengapa unit menjadi tidak aktif beberapa detik setelah start yang berhasil

systemd menyimpulkan status dari proses yang dijalankannya, jadi Type= adalah klaim tentang proses itu, bukan dokumentasi. Dengan Type=simple unit dianggap aktif selama perintah berjalan dan menjadi tidak aktif saat perintah kembali. Klien yang menyerahkan koneksi ke pembantu lalu keluar karena itu tampak seperti crash, bahkan ketika tunnel menyala. Jurnal lalu menunjukkan pola start-stop yang terbaca seperti biner yang rusak.

Baca tipe unit di samping perilaku klien sebelum menyentuh konfigurasi jaringan.

Pilih tipe yang cocok dengan klien

Dua pola mencakup sebagian besar CLI vendor: perintah yang mengonfigurasi sesi lalu keluar, dan perintah yang melakukan fork pembantu sebelum kembali. Masing-masing memerlukan bentuk unit yang berbeda.

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

oneshot dengan RemainAfterExit=true menjaga unit tetap aktif setelah perintah kembali, yang cocok dengan pola konfigurasi-lalu-keluar, dan perintah stop memberi layanan penutupan bersih. Klien yang melakukan fork mempertahankan bentuk yang sama tetapi memerlukan Type=forking agar systemd mengikuti anaknya. Setel Restart=on-failure, RestartSec=30, dan StartLimitBurst yang terbatas, agar gangguan penyedia tidak berubah menjadi loop restart yang mengubur kesalahan.

Jangan pernah biarkan klien yang diawasi menjadi daemon

Pengawas di luar systemd menabrak dinding yang sama. Skrip runit yang menjalankan klien yang sudah menjadi daemon langsung kembali ke pengawas, yang membaca kembalinya sebagai crash lalu menjalankan salinan lain. Setiap pengawas mengharapkan memiliki proses di latar depan, seperti sshd -D tetap di depan. Hapus tanda daemon untuk perintah yang diawasi dan biarkan pengawas menangani latar belakang. Skrip pembungkus yang kembali sebelum tunnel ada menyebabkan kebingungan yang sama.

Proses yang melepaskan diri dari dirinya sendiri tidak terlihat oleh apa pun yang seharusnya mengawasinya.

Sesi berakhir dan membawa tunnel bersamanya

Sesi desktop memiliki klien yang dijalankannya. Akhiri login dan bus sesi menghilang, membawa tunnel bersamanya, yang menjelaskan mengapa koneksi klien grafis sering putus ketika jendela terakhir ditutup. Server sebaiknya memakai unit sistem atau profil NetworkManager yang naik sendiri. Unit pengguna hanya masuk akal ketika tunnel memang harus berakhir bersama login, jadi ikat ke target sesi grafis dan nyatakan itu dalam deskripsinya.

Pengguna layanan adalah separuh lain dari masalah yang sama. Kunci milik root dengan mode 0600 tidak terbaca oleh unit yang berjalan sebagai akun lain, apa pun yang dicapai sudo di shell Anda.

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

Urutkan dependen setelah alamatnya ada

Ketika daemon mengikat ke alamat tunnel yang belum dibuat, ia keluar dengan Cannot assign requested address. Perbaikannya adalah pengurutan eksplisit, bukan loop percobaan ulang.

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

After= mengurutkan pekerjaan, sedangkan Requires= pada unit perangkat mengikat dependen ke keberadaan antarmuka, yang lebih kuat daripada hanya menunggu target jaringan. Muat ulang manajer setelah mengedit dan mulai ulang layanan dependen, lalu baca jurnalnya alih-alih menganggap urutannya berlaku. Kirim keluaran klien ke jurnal dengan StandardOutput=journal atau opsi log, karena klien yang diawasi yang menulis ke berkas yang tidak dibuka siapa pun tampak sama persis dengan yang tidak pernah dimulai.

Lalu boot ulang sekali dan pastikan unit aktif setelah perangkat tunnel muncul. Perbaikan yang hanya diverifikasi dengan systemctl start belum menguji urutan boot yang seharusnya diperbaiki.