Semasa but, unit socket yang mengikat alamat VPN tetap boleh gagal sebelum terowong memberikannya, dan perkhidmatan di belakangnya tidak pernah bermula. Dua suis kelihatan seperti pembetulan dan menyelesaikan dua bahagian berbeza masalah itu. FreeBind membenarkan systemd mencipta pendengar semasa alamat masih tiada. After= hanya menyusun tugas, jadi ia mengubah bila sesuatu bermula tanpa membuat alamat tiba lebih awal.

Dua masalah berbeza, dua suis berbeza

Masalah pertama ialah kegagalan pengikatan: kernel menolak mendengar pada alamat yang tidak dimiliki hos, jadi unit socket gagal serta-merta dan perkhidmatan tidak pernah diaktifkan. Masalah kedua ialah kegagalan kesediaan: alamat akhirnya wujud, tetapi sesuatu cuba menggunakannya sebelum terowong membawa trafik. FreeBind menangani yang pertama dan tidak melakukan apa-apa untuk yang kedua. Arahan urutan tidak menangani kedua-duanya secara langsung, kerana ia hanya menentukan apa yang bermula dalam urutan apa. Menamakan kegagalan yang benar-benar anda hadapi ialah keseluruhan keputusan.

Pastikan yang mana satu anda hadapi daripada jurnal, bukan daripada penerangan perkhidmatan. Kegagalan pengikatan menamakan alamat dan melaporkan bahawa ia tidak boleh diberikan. Kegagalan kesediaan biasanya muncul kemudian, sebagai tamat masa atau sambungan ditolak yang dilihat dari sebelah sana, dengan unit socket yang sihat sepenuhnya dalam log.

FreeBind: pendengar wujud sebelum alamat

FreeBind memberitahu kernel untuk membenarkan pengikatan pada alamat bukan setempat, supaya systemd boleh mencipta socket pendengar semasa but dan menyerahkannya kepada aplikasi setiap kali aplikasi bermula. Itulah maksud pengaktifan socket, dan sebab socket boleh bertahan lebih lama daripada perkhidmatan di belakangnya.

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

Penetapan kosong memadam entri pendengaran yang diwarisi daripada unit vendor sebelum yang baharu ditambah, yang menghalang pendengar wildcard sisa daripada menjawab pada setiap antara muka. Gantikan alamat dan port dengan milik anda sendiri, dan sahkan unit berkesan, bukan hanya fail drop-in. Gunakan drop-in di bawah nama unit dan bukan menyunting fail pakej di tempatnya, kerana kemas kini pakej seterusnya akan menulis ganti suntingan itu dan tidak meninggalkan jejak niat. Kemudian gunakannya melalui prosedur muat semula dan mula semula yang dijangka oleh unit socket.

Rujukan socket systemd mendokumenkan tingkah laku IPv4 dan IPv6 di sebalik pilihan ini, dan perincian pentingnya ialah ia terpakai pada pengikatan dan bukan pada penghalaan. Tiada apa-apa di dalamnya memberikan alamat atau memulakan VPN. FreeBind ialah kebenaran yang diberikan kepada pendengar, bukan pengganti antara muka.

After= dan Wants=: urutan bukan kesediaan

Urutan dan keperluan ialah paksi berasingan, dan mengelirukannya menghasilkan unit yang bermula dalam urutan betul dan tetap gagal. After=vpn-client.service hanya bermaksud bahawa jika kedua-dua tugas dimulakan, yang ini menunggu yang lain dimulakan. Ia tidak menarik VPN dan tidak menunggu VPN selesai menyambung.

Arahan keperluan seperti Wants= dan Requires= mengendalikan pengaktifan, dan ia berbeza dalam apa yang berlaku apabila kebergantungan gagal: satu meneruskan, yang lain berhenti. Kedua-duanya tidak tahu apa maksud terowong yang bersambung. Proses VPN boleh aktif tanpa alamat diberikan, atau dengan alamat diberikan dan tanpa laluan ke rakan, dan kedua-dua keadaan memenuhi kebergantungan. Jika aplikasi memerlukan alamat itu wujud, modelkan syarat itu secara eksplisit dan bukan menganggap permulaan proses sebagai bukti kesediaan.

Periksa apa yang sebenarnya diisytiharkan oleh unit dengan systemctl cat dan systemctl show -p After -p Wants -p Requires. Drop-in daripada tiga direktori berbeza boleh menambah arahan yang anda tidak pernah tulis, dan systemd hanya membaca unit berkesan.

Apa yang network-online.target tidak lakukan

Unit yang disusun selepas network-online.target menunggu pengurus rangkaian mengisytiharkan rangkaian boleh digunakan, yang merupakan titik penyegerakan semasa but dan bukan syarat berterusan. Ia tidak menyatakan apa-apa tentang sama ada terowong tertentu naik, dan ia tidak akan tercetus semula apabila VPN bersambung semula pada tengah hari. Menganggapnya sebagai pemantau sambungan semula ialah salah baca paling biasa bagi sasaran itu.

Projek systemd mendokumenkan perbezaan itu secara langsung, dan akibat praktikalnya ialah apa-apa yang memerlukan alamat terowong mesti memiliki kebergantungan itu sendiri. Unit yang menunggu network-online dan kemudian mengikat alamat terowong hanya betul apabila terowong kebetulan naik dahulu, dan itu kebetulan dan bukan reka bentuk.

Uji kitaran hayat yang benar-benar anda pilih

Uji but bersih, permintaan selepas alamat muncul, dan tingkah laku selepas VPN jatuh dan kembali. Ketiga-tiga kes itu memisahkan pendengar yang berfungsi daripada perkhidmatan yang berfungsi.

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

Perintah pertama menangkap ralat fail unit sebelum but semula, yang kedua menunjukkan unit bergabung, dan yang ketiga membuktikan sama ada pendengar wujud dan pada alamat mana. Pendengar pada alamat wildcard di tempat anda menjangka alamat terowong ialah tepat sisa yang sepatutnya dibuang oleh ListenStream kosong. Ulangi perintah ketiga selepas VPN bersambung semula untuk melihat sama ada alamat itu berpindah.

Pilih kitaran hayat dengan sengaja: sama ada pendengar terikat bebas yang menunggu alamat stabil kembali, atau perkhidmatan yang berhenti bersama terowong dan bermula semula semasa pemulihan. Itu reka bentuk berbeza dan ia gagal dengan cara berbeza. Kemudian kekalkan dasar akses terikat pada sumber dan laluan yang anda maksudkan, kerana mengikat alamat destinasi tidak memerlukan paket yang diterima tiba melalui antara muka yang dipercayai.

Artikel berkaitan