Mengapa nc -uz tidak dapat membuktikan bahawa pelayan OpenVPN sudah sedia

Menjalankan nc -uz terhadap pelayan OpenVPN hampir tidak mengukur apa-apa, dan manual OpenBSD menyatakannya dalam amaran: imbasan UDP dalam mod itu melaporkan kejayaan sama ada ada sesuatu yang mendengar atau tidak. Status keluar mencerminkan penghantaran tempatan, bukan keadaan jauh, jadi penyelia yang mempercayainya mengekalkan pelayan mati ditanda sihat selagi jadual proses kelihatan munasabah. Menggantikannya bermula dengan memutuskan soalan mana yang perlu dijawab oleh pemeriksaan, kerana proses, pendengar, pengesahan dan kebolehcapaian aplikasi ialah empat pemerhatian berbeza. Pemeriksaan yang menamakan salah satunya berguna; pemeriksaan yang menyiratkan keempat-empatnya ialah beban.

Apa yang boleh dan tidak boleh diperhatikan oleh pemeriksaan UDP

nc -uz menghantar datagram lalu keluar, dan status yang dikembalikannya menerangkan penghantaran tempatan. Port tertutup mungkin menjawab dengan ICMP port unreachable, tetapi tingkah laku terdokumentasi mod imbasan ini tidak menjadikannya kegagalan, dan port yang ditapis tidak memberikan jawapan sama sekali. Jadi senyap dan kejayaan bermaksud perkara yang sama bagi pemanggil.

Itu menjadikan pemeriksaan sebagai ujian tindanan tempatan, bukan pelayan. Ia tidak menetapkan bahawa hos boleh dicapai, port terikat, proses OpenVPN berjalan atau klien boleh mengesahkan. Ujian sambungan TCP lebih kuat kerana jabat tangan memberikan jawapan pasti, tetapi hanya apabila penggunaan benar-benar mendengar pada TCP. Menukar pemeriksaan kepada TCP pada nombor yang sama menguji pendengar yang mungkin tidak wujud, dan terhadap pelayan yang hanya UDP ia akan menggagalkan perkhidmatan yang sihat.

Memadankan pemeriksaan dengan pengangkutan yang dikonfigurasikan datang sebelum mempercayai mana-mana hasil. Penggunaan UDP memerlukan isyarat berbeza, bukan protokol berbeza.

Tiga pemanggil, tiga soalan berbeza

Kesiapan bergantung pada siapa yang bertanya. Pengurus perkhidmatan yang menghidupkan semula proses yang ranap perlu tahu bahawa instans bermula dan mengikat pendengarnya. Pengimbang beban perlu tahu bahawa klien yang tiba sekarang akan diterima. Sistem pemantauan perlu tahu bahawa laluan dari rangkaian sebenar masih membawa sesi ke sumber yang dibenarkan.

Ini bukan pemeriksaan yang sama, dan satu pemeriksaan tidak dapat menutup ketiga-tiganya dengan jujur. Pilih pemanggil dahulu, kemudian buktinya.

Bina pemeriksaan daripada instans semasa

OpenVPN menulis baris permulaan apabila instans selesai memulakan, dan baris itu ialah bukti berguna tentang permulaan tempatan. Bacanya dari permulaan semasa, bukan dari hujung fail yang ditambah, kerana kejayaan minggu lalu dibaca sama seperti kejayaan seminit lalu. Pelayan juga boleh menyelesaikan permulaan sebelum mana-mana klien pernah bersambung, jadi baris itu tidak mengatakan apa-apa tentang pengesahan.

Untuk pemeriksaan permulaan, pasangkan keadaan proses dengan bukti log semasa dan pendengar yang sepadan dengan pengangkutan yang dikonfigurasikan. Pemeriksaan harus gagal apabila proses berjalan tetapi belum selesai memulakan, yang bermaksud pertanyaan log mesti dihadkan kepada but 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 output, tiga dakwaan: unit aktif, but ini menghasilkan baris permulaan, dan sesuatu memegang port UDP. Tiada satu pun mengatakan klien boleh bersambung. Pisahkan ketiga-tiganya pada halaman status supaya insiden tidak runtuh menjadi satu titik hijau.

Rosakkannya dengan sengaja dan perhatikan pemeriksaan

Pemeriksaan hanya boleh dipercayai setelah anda melihatnya gagal. Hentikan pelayan, jalankan pemeriksaan dan sahkan hasil yang dijangka. Kemudian mulakannya semula dan sahkan bahawa pemeriksaan pulih tanpa sebarang 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 sedangkan tiada apa yang terikat, dan itulah keseluruhan masalah dalam satu baris. Yang pertama ss tidak mencetak apa-apa, permulaan semula berjaya, dan yang kedua ss menunjukkan pendengar sekali lagi. Jika pemeriksaan anda lulus terhadap pelayan yang dihentikan, ia mengukur tindanan tempatan dan bukan yang lain.

Kegagalan sebaliknya juga penting. Pemeriksaan yang gagal terhadap pelayan sihat menyebabkan permulaan semula yang tidak pernah diperlukan, dan gelung permulaan semula itu sendiri satu gangguan. Uji kedua-dua arah sebelum anda menyambungkan pemeriksaan kepada apa-apa yang boleh bertindak ke atasnya.

Apa yang sepatutnya dikatakan baris status

Catat sempadan mana yang diliputi setiap pemeriksaan: proses, pendengar, pengesahan atau aplikasi. Satu pemeriksaan jarang meliputi lebih daripada satu, dan halaman status yang memadatkannya menjadi “up” menyembunyikan perbezaan yang penting semasa insiden. Untuk laluan rangkaian, gunakan klien sebenar dengan identiti khusus, biarkan ia menyelesaikan jabat tangan dan satu operasi dibenarkan yang tidak berbahaya, kemudian putuskan sambungan. Itu melatih saluran kawalan, dasar pengesahan dan pendengar dalam satu langkah.

Jauhkan identiti itu daripada pengguna sebenar dan berikan izin minimum yang diperlukan oleh pemeriksaan. Pemeriksaan kesiapan dengan akses luas ialah permukaan serangan baharu yang ditambah demi kemudahan. Putarkan kelayakannya seperti mana-mana akaun lain, kerana pemeriksaan yang berhenti mengesahkan kelihatan sama seperti pelayan yang berhenti menerima klien.

Namakan sempadan itu dalam teks amaran, supaya penyahut pertama tahu sama ada perlu melihat unit, soket, sijil atau laluan. Pemeriksaan yang tidak dapat menyatakan apa yang dibuktikannya akan dipercayai atas sebab yang salah, dan begitulah pemeriksaan netcat bertahan pada mulanya.