Me-restart OpenVPN setiap hari? Pilih kegagalannya, bukan jamnya

Anda mewarisi tugas cron yang me-restart OpenVPN setiap hari pukul 04:10, dan tugas itu sudah menjaga semuanya stabil selama setahun. Tugas itu juga memutus tunnel yang sehat pada jam tetap dan tidak melakukan apa pun untuk gangguan yang sebenarnya terjadi saat makan siang. Restart berdasarkan kalender adalah keputusan perawatan. Pemulihan adalah rancangan lain dengan pemicu tertentu.

Tiga bentuk kegagalan membutuhkan tiga pemilik berbeda. Pilih kegagalannya lebih dulu, dan mekanismenya akan mengikuti.

Tiga kegagalan, tiga pemilik

Tunnel bisa tetap aktif saat peer-nya sudah hilang: prosesnya berjalan, antarmukanya ada, dan tidak ada hal berguna yang melewatinya. Proses bisa mati sementara peer-nya baik-baik saja, dan dalam hal itu hanya apa yang memulainya yang bisa menghidupkannya kembali. Aplikasi di balik tunnel bisa rusak sementara tunnel dan peer-nya sama-sama sehat, dan me-restart klien saat itu justru memperluas gangguan tanpa menyentuh penyebabnya. Memisahkan ketiga kasus itulah keseluruhan keputusannya.

Masing-masing punya sinyal dan pemiliknya sendiri. Keaktifan hidup milik protokol VPN, siklus hidup proses milik manajer layanan, dan kesehatan aplikasi milik pemantauan dengan mandat sempit.

Apa yang bisa dan tidak bisa dilakukan opsi keaktifan hidup

keepalive adalah pembantu yang mengembang menjadi pasangan ping dan ping-restart, sebagaimana dijelaskan referensi opsi tautan, dan batas waktu yang dihasilkannya tidak identik di server dan klien. Nilai yang didorong server juga dapat menimpa apa yang dikonfigurasi klien secara lokal, sehingga batas waktu yang terlihat benar di berkas lokal mungkin bukan yang berlaku.

Itu menjadikannya alat yang tepat untuk peer yang hilang dan alat yang salah untuk proses yang mati, karena proses yang sudah keluar tidak dapat menjalankan pengatur waktunya sendiri. Ia juga tidak mengatakan apa pun tentang apakah aplikasi di balik tunnel menjawab, karena pertukaran terjadi antara dua titik akhir VPN. Menyalin pasangan batas waktu dari penerapan lain tanpa memeriksa peran, gangguan yang diharapkan, dan perilaku autentikasi ulang adalah cara tunnel yang stabil mulai bergetar.

Apa yang dimiliki manajer layanan

Jika daemon keluar, manajer yang memulainya yang memutuskan apa yang terjadi berikutnya. Kebijakan restart yang berpatokan pada kegagalan, dengan jeda dan batas laju mulai, menangani crash loop tanpa menjadikannya fork bomb. Setelan itu menanggapi hasil proses dan batas waktu, dan tidak mendeteksi proses yang hidup tetapi tidak berguna. Itu bukan celah yang perlu ditambal dengan kebijakan yang lebih luas; itu batas antara siklus hidup dan keaktifan hidup.

Kepemilikan sama pentingnya dengan setelan. Koneksi yang dimulai oleh manajer jaringan desktop harus mempertahankan pengaturan pemulihan manajer itu, dan menambahkan unit layanan pesaing untuk antarmuka yang sama memberi satu tunnel dua pemilik. Pilih satu dan tuliskan yang mana.

Kapan restart terjadwal sah dilakukan

Restart berjadwal bisa menjadi tindakan perawatan yang wajar: ia punya pemilik, jendela, instans bernama, dan jalur masuk yang mandiri. Yang tidak boleh adalah menjadikannya kebijakan keandalan umum yang juga memutus semua orang pada jam tetap.

Jika restart itu ada untuk menghindari kebocoran yang diketahui atau keadaan macet, sebutkan hal itu dalam deskripsi unit, karena jika tidak, orang berikutnya akan menyimpannya selamanya.

Uji kasus yang penting: peer menghilang sementara proses tetap aktif, proses keluar, percobaan ulang membutuhkan kredensial baru, dan tunnel kembali sementara aplikasi tetap rusak. Perhatikan komponen mana yang bereaksi dan keadaan apa yang ditinggalkannya.

Pertanyaan yang tepat bukan seberapa sering me-restart, melainkan apa yang seharusnya menyadari kegagalan lebih dulu.