Mengapa klien OpenVPN anda kekal mati selepas satu tamat masa

Isnin pagi: terowong yang naik pada Jumaat sudah hilang, antara muka masih tersenarai, dan tiada apa dalam jurnal yang menyatakan sesiapa perasan. Hos berada dalam talian, papan pemuka berwarna hijau, dan semua yang dihantarnya sepanjang hujung minggu keluar melalui antara muka fizikal. Di sini dua keputusan bebas hilang: satu tentang sama ada proses klien bertahan daripada kegagalan sementara dan satu tentang sama ada sesuatu di atasnya memulakan semula proses selepas ia keluar. Membaiki salah satu sahaja membiarkan jurang yang lain terbuka.

Mulakan daripada apa yang sebenarnya dilakukan oleh unit, bukan daripada apa yang didakwa oleh pemantauan. systemctl status openvpn-client@office dan journalctl -u openvpn-client@office -n 50 menunjukkan sebab keluar dan baris terakhir yang ditulis klien sebelum pergi.

Proses keluar sebelum sesiapa perasan

Klien yang hilang tanpa ralat biasanya keluar dengan sengaja. Profil yang menentukan tingkah laku itu, bukan pengurus perkhidmatan: ping-exit menamatkan proses sebaik sahaja rakan berhenti membalas, manakala ping-restart mengekalkan proses dan menyambung semula di dalamnya. Had sesi dan pemasa tidak aktif menghasilkan gambaran yang sama dari luar: tanpa terowong dan tanpa penggera.

Dua arahan ping tidak boleh muncul bersama dalam satu profil, jadi pilih satu dan catat pilihan itu. Lihat juga pelayan, kerana ping-exit miliknya sendiri menutup sesi apa sahaja yang diminta klien, dan hanya log pelayan mencatat siapa yang membuat keputusan itu.

Memilih antara ping-exit dan ping-restart

Pilih ping-restart untuk komputer riba atau tapak jauh yang perlu pulih sendiri, dan simpan ping-exit untuk kes di mana terowong mati mesti menghentikan proses supaya sesuatu yang lain boleh bertindak ke atasnya. Nombor kurang penting daripada hubungan: ping 10 dengan ping-restart 60 bermaksud sepuluh saat senyap sebelum pemeriksaan dan enam puluh sebelum mula semula, yang agresif pada pautan mudah alih yang rugi dan munasabah pada pautan berwayar. Tulis sebabnya di sebelah baris, kerana pembaca seterusnya akan menganggap nilai lalai itu disengajakan.

Kemudian pastikan proses memang yang keluar. Unit yang melaporkan aktif semasa terowong mati ialah kegagalan lain, yang dibincangkan di bawah.

Pengawasan yang benar-benar memulakan semula unit

Pada hos systemd, perubahan tahan lama terkecil ialah satu fail drop-in: Restart=on-failure dan RestartSec=10 dalam /etc/systemd/system/[email protected]/restart.conf. Drop-in hanya dibaca apabila systemd memuat semula definisinya sendiri, jadi jalankan systemctl daemon-reload selepas itu. Sahkan dengan systemctl show -p Restart -p ExecMainStatus openvpn-client@office daripada menganggap nilainya sudah masuk. Instans dalam nama fail mesti profil yang benar-benar dimuatkan oleh unit, jadi fail yang ditulis untuk office tidak memberi kesan kepada openvpn-client@home.

on-failure mengabaikan satu kes: keluar bersih dengan status sifar. Sesetengah laluan pembongkaran berakhir begitu, jadi baca status yang direkodkan daripada mempercayai perkataan halaman manual. Jika klien anda berputus asa dengan sifar, anda memerlukan Restart=always, dan kosnya ialah profil yang benar-benar rosak terus kembali sehingga had kadar mula tercetus dan jurnal penuh.

Restart=always juga tercetus selepas hentian yang disengajakan. Gunakan systemctl stop untuk penyelenggaraan, dan topeng unit itu jika ia mesti kekal mati semasa anda bekerja.

Tangkap kebocoran semasa terowong mati

Pengawasan memulihkan terowong; ia tidak menghalang trafik keluar semasa terowong tiada. persist-tun mengekalkan peranti dan laluannya antara sambungan semula, yang memudahkan dan membuka tetingkap. Peranti bertahan, laluan masih menuju ke arahnya, dan paket mengalir keluar tanpa perlindungan dan tanpa laporan. Itu pilihan dasar, bukan nilai lalai yang neutral.

Apabila hos tidak boleh mengeluarkan paket tanpa perlindungan sama sekali, hanya tembok api boleh menjaminnya. Peraturan keluar yang membenarkan antara muka terowong dan alamat pelayan VPN sambil menggugurkan semua yang lain masih berkuat kuasa selepas klien mati, dan tiada apa dalam konfigurasi klien sendiri boleh menapis trafik yang tidak dibawa oleh klien.

Uji dengan menghentikan klien secara sengaja. Jalankan systemctl stop openvpn-client@office, kemudian curl -m 5 https://example.com, yang sepatutnya gagal dan bukan berjaya melalui pautan fizikal. Kejayaan bermakna peraturan tembok api tiada atau terlalu permisif.

Sambung semula, sahkan terowong membawa trafik lagi, dan hanya kemudian tambah pemeriksaan itu ke pemantauan. Meninjau ip addr dari cron untuk peranti tun ialah pengawasan yang paling kerap gagal, kerana dengan persist-tun peranti hidup lebih lama daripada sesi dan pemeriksaan melaporkan sihat sedangkan tiada yang dibawa.