FreeBind versus After=: mengikat socket systemd ke alamat VPN

Saat boot, unit socket yang mengikat alamat VPN tetap bisa gagal sebelum tunnel memberikannya, dan layanan di belakangnya tidak pernah mulai. Dua sakelar tampak seperti perbaikan dan menyelesaikan dua bagian berbeda dari masalah itu. FreeBind membiarkan systemd membuat listener saat alamatnya masih belum ada. After= hanya mengurutkan tugas, jadi ia mengubah kapan sesuatu mulai tanpa membuat alamat datang lebih cepat.

Dua masalah berbeda, dua sakelar berbeda

Masalah pertama adalah kegagalan pengikatan: kernel menolak mendengarkan pada alamat yang tidak dimiliki host, sehingga unit socket langsung gagal dan layanan tidak pernah diaktifkan. Masalah kedua adalah kegagalan kesiapan: alamatnya akhirnya ada, tetapi sesuatu mencoba memakainya sebelum tunnel membawa lalu lintas. FreeBind menangani yang pertama dan tidak melakukan apa pun untuk yang kedua. Direktif urutan tidak menangani keduanya secara langsung, karena mereka hanya memutuskan apa yang mulai dalam urutan apa. Menamai kegagalan yang benar-benar Anda miliki adalah seluruh keputusannya.

Pastikan mana dari keduanya yang Anda miliki dari jurnal, bukan dari deskripsi layanan. Kegagalan pengikatan menyebutkan sebuah alamat dan melaporkan bahwa alamat itu tidak dapat diberikan. Kegagalan kesiapan biasanya muncul kemudian, sebagai timeout atau koneksi yang ditolak yang terlihat dari sisi jauh, dengan unit socket yang sepenuhnya sehat di log.

FreeBind: listener ada sebelum alamatnya

FreeBind memberi tahu kernel untuk mengizinkan pengikatan ke alamat non-lokal, sehingga systemd dapat membuat socket pendengar saat boot dan menyerahkannya ke aplikasi setiap kali aplikasi mulai. Itulah inti aktivasi socket, dan alasan socket dapat bertahan lebih lama daripada layanan di belakangnya.

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

Penetapan kosong menghapus entri pendengaran yang diwarisi dari unit vendor sebelum yang baru ditambahkan, yang mencegah listener wildcard sisa menjawab di setiap antarmuka. Ganti alamat dan port dengan milik Anda sendiri, dan verifikasi unit efektif, bukan hanya berkas drop-in. Gunakan drop-in dengan nama unit alih-alih menyunting berkas paket di tempatnya, karena pembaruan paket berikutnya akan menimpa suntingan itu dan tidak meninggalkan jejak niat. Lalu terapkan melalui prosedur muat ulang dan mulai ulang yang diharapkan unit socket.

Referensi socket systemd mendokumentasikan perilaku IPv4 dan IPv6 di balik opsi ini, dan detail pentingnya adalah opsi ini berlaku pada pengikatan, bukan pada perutean. Tidak ada di dalamnya yang memberikan alamat atau menjalankan VPN. FreeBind adalah izin yang diberikan kepada listener, bukan pengganti antarmuka.

After= dan Wants=: urutan bukan kesiapan

Urutan dan persyaratan adalah sumbu terpisah, dan mencampurnya menghasilkan unit yang mulai dalam urutan benar dan tetap gagal. After=vpn-client.service hanya berarti bahwa jika kedua tugas dimulai, yang ini menunggu yang lain dimulai. Ia tidak menarik VPN, dan tidak menunggu VPN selesai terhubung.

Direktif persyaratan seperti Wants= dan Requires= menangani aktivasi, dan keduanya berbeda dalam apa yang terjadi ketika dependensi gagal: satu melanjutkan, yang lain berhenti. Tidak satu pun mengetahui apa arti tunnel yang terhubung. Proses VPN dapat aktif tanpa alamat yang diberikan, atau dengan alamat yang diberikan dan tanpa rute ke rekan, dan kedua keadaan memenuhi dependensi. Jika aplikasi membutuhkan alamat itu ada, modelkan kondisi tersebut secara eksplisit alih-alih memperlakukan mulai proses sebagai bukti kesiapan.

Periksa apa yang sebenarnya dideklarasikan unit dengan systemctl cat dan systemctl show -p After -p Wants -p Requires. Drop-in dari tiga direktori berbeda dapat menambahkan direktif yang tidak pernah Anda tulis, dan systemd hanya membaca unit efektif.

Apa yang tidak dilakukan network-online.target

Unit yang diurutkan setelah network-online.target menunggu manajer jaringan menyatakan jaringan dapat digunakan, yang merupakan titik sinkronisasi saat boot dan bukan kondisi berkelanjutan. Ia tidak mengatakan apa pun tentang apakah tunnel tertentu aktif, dan tidak akan terpicu lagi ketika VPN terhubung kembali pada sore hari. Memperlakukannya sebagai pemantau penyambungan ulang adalah salah baca paling umum dari target itu.

Proyek systemd mendokumentasikan perbedaan itu secara langsung, dan akibat praktisnya adalah apa pun yang membutuhkan alamat tunnel harus memiliki dependensi itu sendiri. Unit yang menunggu network-online lalu mengikat alamat tunnel hanya benar ketika tunnel kebetulan naik lebih dulu, dan itu kebetulan, bukan rancangan.

Uji siklus hidup yang benar-benar Anda pilih

Uji boot bersih, permintaan setelah alamat muncul, dan perilaku setelah VPN putus dan kembali. Ketiga kasus itu memisahkan listener yang berfungsi dari layanan yang berfungsi.

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

Perintah pertama menangkap kesalahan berkas unit sebelum reboot, yang kedua menampilkan unit gabungan, dan yang ketiga membuktikan apakah listener ada dan pada alamat mana. Listener pada alamat wildcard di tempat Anda mengharapkan alamat tunnel adalah tepat sisa yang seharusnya dihapus oleh ListenStream kosong. Ulangi perintah ketiga setelah VPN tersambung ulang untuk melihat apakah alamatnya berpindah.

Pilih siklus hidup dengan sengaja: entah listener yang terikat bebas yang menunggu alamat stabil kembali, atau layanan yang berhenti bersama tunnel dan mulai lagi saat pulih. Itu rancangan berbeda dan gagal dengan cara berbeda. Lalu pertahankan kebijakan akses terikat pada sumber dan jalur yang Anda maksudkan, karena mengikat alamat tujuan tidak mengharuskan paket yang diterima tiba melalui antarmuka tepercaya.