OpenVPN: bind lokal gagal saat boot — tunggu atau coba ulang

Untuk server OpenVPN yang tidak mau start saat boot, ditawarkan dua perbaikan: tunggu alamatnya, atau biarkan layanan mencoba ulang sampai bind berhasil. Keduanya menangani gejala yang sama dengan perilaku kegagalan berbeda. Menunggu mengodekan prasyarat tertentu dan gagal dengan berisik saat prasyarat itu tidak ada; mencoba ulang menyembunyikan prasyarat dan terus mencoba. Mana yang cocok untuk unit Anda bergantung pada apakah alamat itu dependensi yang dirancang atau kebetulan waktu.

Keduanya lebih baik daripada tidur tetap, yang tidak menunggu apa pun dan tidak melaporkan apa yang ditunggunya.

Apa yang sebenarnya dituntut opsi local

local menamai alamat tempat daemon mengikat socket-nya, dan mengikat ke alamat yang belum ada langsung gagal dengan galat tentang alamat yang diminta. Ketika opsi tidak ada, daemon mendengarkan di semua alamat, itulah sebabnya profil yang sama berfungsi pada mesin yang antarmukanya belum aktif: ia mendengarkan di mana-mana alih-alih di satu alamat yang Anda sebutkan. Perbedaan itulah seluruh kegagalannya, dan ia tetap tak terlihat sampai reboot.

Persyaratannya bukan bahwa antarmuka aktif dalam pengertian umum. Alamat harus ditetapkan ke antarmuka yang benar pada saat pengikatan, dan itu harus antarmuka dasar, bukan terowongan yang nanti dibuat oleh daemon yang sama. Pemeriksaan yang dijalankan beberapa menit setelah login tidak membuktikan apa pun tentang urutan boot.

Menunggu alamat versus mencoba ulang pengikatan

Menunggu berarti ExecStartPre yang melakukan polling sampai alamat muncul, dengan jumlah percobaan terbatas dan keluar bukan nol saat waktu habis. Mencoba ulang berarti membiarkan proses utama gagal dan meminta manajer layanan menjalankannya lagi, misalnya Restart=on-failure dengan RestartSec=5. Yang pertama melaporkan prasyarat yang hilang sebagai unit gagal, sedangkan yang kedua melaporkannya sebagai rangkaian restart yang akhirnya berhenti, yang lebih berisik di jurnal tetapi bertahan menghadapi alamat yang datang terlambat karena alasan yang tidak dapat Anda duga.

Utamakan menunggu ketika alamat adalah dependensi yang dirancang, dan utamakan mencoba ulang ketika alamat biasanya muncul tetapi waktunya bervariasi. Menggabungkan keduanya wajar: tunggu terbatas mencakup kasus umum dan kebijakan restart mencakup pengecualian. Yang tidak boleh dilakukan keduanya adalah berjalan selamanya, karena unit yang mencoba ulang tanpa henti menyembunyikan kesalahan konfigurasi alih-alih melaporkannya.

Mengapa network-online.target tidak cukup

network-online.target menjanjikan apa pun yang dimaksud implementasi jaringan aktif dengan online, dan tidak lebih. Dengan systemd-networkd, systemd-networkd-wait-online memutuskan kapan target itu tercapai, dan gagasan bawaan tentang online dapat terpenuhi sebelum alamat spesifik Anda ada. Di bawah NetworkManager, layanan wait-online menerapkan aturannya sendiri. Mengurutkan setelah target adalah dasar yang sehat, bukan jaminan bahwa satu alamat, jawaban DNS, atau rekan jauh siap.

Penalaran yang sama menyingkirkan alternatif yang biasa. Entri autostart desktop menunggu sesi pengguna yang mungkin tidak pernah terbuka di server, dan perintah cron yang tertunda menambahkan waktu berlalu tanpa menyebut sumber daya yang diharapkannya muncul. Keduanya dapat tampak berhasil selama berbulan-bulan lalu gagal pada satu boot yang penting.

Periksa pengikatan setelah boot dingin

Verifikasi dengan boot dingin sungguhan, bukan restart layanan, karena restart mewarisi alamat yang harus dibuat oleh urutan boot. Setelah boot, ss -lntp atau ss -lunp menunjukkan alamat lokal yang benar-benar diikat oleh setiap pendengar, dan journalctl -b -u openvpn-server@server menunjukkan apakah percobaan pertama gagal. Bandingkan alamat yang terikat dengan yang ada di profil, lalu ulangi perbandingan setelah koneksi ulang jaringan.

Jika profil tidak pernah memerlukan alamat tetap, menghapus local adalah penyederhanaan yang sah, tetapi jadikan itu keputusan keamanan, bukan kebiasaan pemecahan masalah.

Memperlebar pendengar mengubah siapa yang dapat menjangkaunya, jadi pasangkan perubahan itu dengan kebijakan firewall yang seharusnya membatasinya. Layanan yang start andal di setiap antarmuka belum menyelesaikan masalah aslinya; ia memindahkan masalah ke tepi jaringan.