Mengapa nc -uz tidak dapat membuktikan bahwa server OpenVPN siap

Menjalankan nc -uz terhadap server OpenVPN hampir tidak mengukur apa pun, dan manual OpenBSD mengatakannya dalam peringatannya: pemindaian UDP dalam mode itu melaporkan sukses entah ada yang mendengarkan atau tidak. Status keluar mencerminkan pengiriman lokal, bukan keadaan jauh, sehingga pengawas yang memercayainya tetap menandai server mati sebagai sehat selama tabel proses tampak masuk akal. Menggantikannya dimulai dengan memutuskan pertanyaan mana yang harus dijawab pemeriksaan, karena proses, pendengar, autentikasi, dan keterjangkauan aplikasi adalah empat pengamatan berbeda. Pemeriksaan yang menyebut salah satunya berguna; pemeriksaan yang menyiratkan keempatnya adalah beban.

Apa yang dapat dan tidak dapat diamati pemeriksaan UDP

nc -uz mengirim datagram lalu keluar, dan status yang dikembalikannya menjelaskan pengiriman lokal. Port tertutup mungkin menjawab dengan ICMP port unreachable, tetapi perilaku terdokumentasi mode pemindaian ini tidak mengubahnya menjadi kegagalan, dan port yang difilter tidak memberikan jawaban sama sekali. Jadi diam dan sukses berarti hal yang sama bagi pemanggil.

Itu membuat pemeriksaan menjadi uji tumpukan lokal, bukan uji server. Ia tidak menetapkan bahwa host dapat dijangkau, port terikat, proses OpenVPN berjalan, atau klien dapat melakukan autentikasi. Uji koneksi TCP lebih kuat karena jabat tangan memberi jawaban pasti, tetapi hanya bila penerapan benar-benar mendengarkan di TCP. Mengalihkan pemeriksaan ke TCP pada nomor yang sama menguji pendengar yang mungkin tidak ada, dan terhadap server yang hanya UDP ia akan menggagalkan layanan yang sehat.

Mencocokkan pemeriksaan dengan transport yang dikonfigurasi datang sebelum memercayai salah satu hasil. Penerapan UDP memerlukan sinyal berbeda, bukan protokol berbeda.

Tiga pemanggil, tiga pertanyaan berbeda

Kesiapan bergantung pada siapa yang bertanya. Manajer layanan yang menyalakan ulang proses yang crash perlu tahu bahwa instans mulai dan mengikat pendengarnya. Penyeimbang beban perlu tahu bahwa klien yang datang sekarang akan diterima. Sistem pemantauan perlu tahu bahwa jalur dari jaringan nyata masih membawa sesi ke sumber daya yang diizinkan.

Ini bukan pemeriksaan yang sama, dan satu pemeriksaan tidak dapat menutupi ketiganya dengan jujur. Pilih pemanggilnya dulu, lalu buktinya.

Bangun pemeriksaan dari instans saat ini

OpenVPN menulis baris mulai saat instans selesai menginisialisasi, dan baris itu adalah bukti berguna tentang mulai lokal. Bacalah dari mulai saat ini, bukan dari ekor berkas yang ditambahi, karena sukses minggu lalu terbaca persis seperti sukses satu menit lalu. Server juga dapat menyelesaikan inisialisasi sebelum ada klien yang pernah terhubung, jadi baris itu tidak mengatakan apa pun tentang autentikasi.

Untuk pemeriksaan mulai, pasangkan status proses dengan bukti log saat ini dan pendengar yang cocok dengan transport yang dikonfigurasi. Pemeriksaan harus gagal ketika proses berjalan tetapi belum selesai menginisialisasi, yang berarti kueri log harus dibatasi pada boot ini dan unit ini.

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

Tiga keluaran, tiga klaim: unit aktif, boot ini menghasilkan baris inisialisasi, dan ada sesuatu yang memegang port UDP. Tidak satu pun mengatakan klien dapat terhubung. Pisahkan ketiganya di halaman status agar insiden tidak runtuh menjadi satu titik hijau.

Rusak dengan sengaja dan amati pemeriksaannya

Pemeriksaan baru dapat dipercaya setelah Anda melihatnya gagal. Hentikan server, jalankan pemeriksaan, dan pastikan hasil yang Anda harapkan. Lalu nyalakan lagi dan pastikan pemeriksaan pulih tanpa perubahan lain.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

Baca blok itu baris demi baris. Perintah netcat mencetak exit=0 sementara tidak ada yang terikat, dan itulah seluruh masalah dalam satu baris. Yang pertama ss tidak mencetak apa pun, penyalakan ulang berhasil, dan yang kedua ss menunjukkan pendengarnya lagi. Jika pemeriksaan Anda lolos terhadap server yang dihentikan, ia mengukur tumpukan lokal dan bukan yang lain.

Kegagalan sebaliknya juga penting. Pemeriksaan yang gagal terhadap server sehat menyebabkan penyalakan ulang yang tidak pernah diperlukan, dan putaran penyalakan ulang sendiri adalah gangguan. Uji kedua arah sebelum Anda menghubungkan pemeriksaan ke apa pun yang dapat bertindak atasnya.

Apa yang seharusnya dikatakan baris status

Catat batas mana yang dicakup setiap pemeriksaan: proses, pendengar, autentikasi, atau aplikasi. Satu pemeriksaan jarang mencakup lebih dari satu, dan halaman status yang memadatkannya menjadi “up” menyembunyikan perbedaan yang penting saat insiden. Untuk jalur jaringan, gunakan klien sungguhan dengan identitas khusus, biarkan ia menyelesaikan jabat tangan dan satu operasi diizinkan yang tidak berbahaya, lalu putuskan. Itu melatih kanal kendali, kebijakan autentikasi, dan pendengar dalam satu langkah.

Jauhkan identitas itu dari pengguna nyata dan beri ia izin minimum yang dibutuhkan pemeriksaan. Pemeriksaan kesiapan dengan akses luas adalah permukaan serangan baru yang ditambahkan demi kenyamanan. Putar kredensialnya seperti akun lain, karena pemeriksaan yang berhenti mengautentikasi terlihat persis seperti server yang berhenti menerima klien.

Sebutkan batasnya dalam teks peringatan, agar penanggap pertama tahu apakah harus melihat unit, soket, sertifikat, atau rute. Pemeriksaan yang tidak dapat mengatakan apa yang dibuktikannya akan dipercaya karena alasan yang salah, dan begitulah pemeriksaan netcat bertahan sejak awal.