Mengapa klien OpenVPN Anda tetap mati setelah satu kali timeout

Senin pagi: terowongan yang naik hari Jumat sudah hilang, antarmuka masih terdaftar, dan tidak ada apa pun di jurnal yang menyebut seseorang menyadarinya. Host online, dasbor hijau, dan semua yang dikirimnya akhir pekan keluar lewat antarmuka fisik. Ada dua keputusan independen yang hilang di sini: satu tentang apakah proses klien bertahan dari kegagalan sesaat dan satu tentang apakah sesuatu di atasnya menjalankan proses lagi setelah keluar. Memperbaiki salah satu saja membiarkan celah lainnya terbuka.

Mulailah dari apa yang benar-benar dilakukan unit, bukan dari apa yang diklaim pemantauan. systemctl status openvpn-client@office dan journalctl -u openvpn-client@office -n 50 menunjukkan alasan keluar dan baris terakhir yang ditulis klien sebelum pergi.

Proses keluar sebelum ada yang menyadarinya

Klien yang hilang tanpa kesalahan biasanya keluar dengan sengaja. Profil yang menentukan perilaku itu, bukan manajer layanan: ping-exit mengakhiri proses begitu lawan berhenti membalas, sedangkan ping-restart mempertahankan proses dan menyambung ulang di dalamnya. Batas sesi dan timer tidak aktif menghasilkan gambaran yang sama dari luar: tanpa terowongan dan tanpa alarm.

Dua direktif ping tidak dapat muncul bersama dalam satu profil, jadi pilih satu dan catat pilihannya. Periksa juga server, karena ping-exit miliknya sendiri menutup sesi apa pun yang diminta klien, dan hanya log server yang mencatat siapa yang mengambil keputusan itu.

Memilih antara ping-exit dan ping-restart

Pilih ping-restart untuk laptop atau lokasi terpencil yang harus menyembuhkan dirinya sendiri, dan simpan ping-exit untuk kasus di mana terowongan mati harus menghentikan proses agar hal lain dapat menindaknya. Angka kurang penting daripada hubungannya: ping 10 dengan ping-restart 60 berarti sepuluh detik senyap sebelum pemeriksaan dan enam puluh sebelum mulai ulang, yang agresif pada tautan seluler yang lossy dan wajar pada tautan kabel. Tulis alasannya di samping baris, karena pembaca berikutnya akan menganggap nilai bawaan itu disengaja.

Lalu pastikan bahwa proses memang yang keluar. Unit yang melaporkan aktif saat terowongan mati adalah kegagalan lain, yang dibahas lebih jauh di bawah.

Pengawasan yang benar-benar memulai ulang unit

Pada host systemd, perubahan tahan lama terkecil adalah satu berkas drop-in: Restart=on-failure dan RestartSec=10 di /etc/systemd/system/[email protected]/restart.conf. Drop-in hanya dibaca saat systemd memuat ulang definisinya sendiri, jadi jalankan systemctl daemon-reload sesudahnya. Verifikasi dengan systemctl show -p Restart -p ExecMainStatus openvpn-client@office alih-alih menganggap nilainya sudah masuk. Instance dalam nama berkas harus profil yang benar-benar dimuat unit, sehingga berkas yang ditulis untuk office tidak berpengaruh bagi openvpn-client@home.

on-failure mengabaikan satu kasus: keluar bersih dengan status nol. Beberapa jalur pembongkaran berakhir begitu, jadi baca status yang tercatat alih-alih memercayai redaksi halaman manual. Jika klien Anda menyerah dengan nol, Anda memerlukan Restart=always, dan harganya adalah profil yang benar-benar rusak terus kembali sampai batas laju mulai terpicu dan jurnal penuh.

Restart=always juga terpicu setelah penghentian yang disengaja. Gunakan systemctl stop untuk pemeliharaan, dan mask unit jika harus tetap mati selama Anda bekerja.

Menangkap kebocoran selagi terowongan mati

Pengawasan membuat terowongan kembali; itu tidak mencegah lalu lintas keluar saat terowongan tidak ada. persist-tun mempertahankan perangkat dan rutenya antar penyambungan ulang, yang nyaman dan membuka jendela. Perangkat bertahan, rute masih mengarah ke sana, dan paket mengalir keluar tanpa perlindungan dan tanpa laporan. Itu pilihan kebijakan, bukan nilai bawaan yang netral.

Ketika host tidak boleh mengeluarkan paket tanpa perlindungan sama sekali, hanya firewall yang dapat menjaminnya. Aturan keluar yang mengizinkan antarmuka terowongan dan alamat server VPN sambil menjatuhkan semua yang lain tetap berlaku setelah klien mati, dan tidak ada apa pun dalam konfigurasi klien sendiri yang dapat menyaring lalu lintas yang tidak dibawa klien.

Ujilah dengan menghentikan klien secara sengaja. Jalankan systemctl stop openvpn-client@office, lalu curl -m 5 https://example.com, yang seharusnya gagal alih-alih berhasil melalui tautan fisik. Keberhasilan berarti aturan firewall hilang atau terlalu permisif.

Sambung ulang, pastikan terowongan kembali membawa lalu lintas, dan barulah tambahkan pemeriksaan ke pemantauan. Menanyakan ip addr dari cron untuk perangkat tun adalah pengawasan yang paling sering gagal, karena dengan persist-tun perangkat hidup lebih lama daripada sesi dan pemeriksaan melaporkan sehat padahal tidak ada yang dibawa.