Sambungan ditolak bukan masalah sijil: buku panduan VPN

Klien berkata sambungan ditolak sejurus selepas anda menjana semula CRL, jadi CRL kelihatan bersalah. Ia tidak. Penolakan ialah jawapan lapisan pengangkutan, dan pengesahan sijil berlaku kemudian, di dalam handshake terowong. Masa itu konteks, bukan bukti.

Dua pemeriksaan memisahkan kes itu dalam masa kurang seminit, dan kedua-duanya tidak menyentuh tetapan kepercayaan.

Baca ralat pada lapisan yang menghasilkannya

ECONNREFUSED daripada connect bermaksud percubaan pengangkutan ditolak: sesuatu menjawab dengan reset, atau stack melaporkan port yang tidak boleh dicapai. Masalah sijil tidak boleh menghasilkan ralat itu, kerana handshake TLS tidak pernah bermula tanpa sambungan pengangkutan. Jika anda melihat penolakan, klien tidak pernah cukup jauh untuk mengemukakan sijil. Fakta tunggal itu menyingkirkan pembatalan sebagai punca.

Sebaliknya juga benar. Sijil yang dibatalkan menghasilkan sambungan TCP yang selesai dan handshake yang gagal, direkodkan pada pelayan sebagai ralat pengesahan.

Penolakan TCP: tiada siapa mendengar

Untuk TCP, periksa sama ada instans yang dimaksudkan berjalan dan terikat pada alamat dan port dalam profil. ss -lntp menunjukkan pendengar, dan ketiadaan salah satunya ialah penjelasan biasa. Tembok api yang menolak dan bukannya menggugurkan menghasilkan mesej yang sama di sisi klien, sebab itu anda memeriksa kedua-duanya.

Periksa juga keluarga alamat. Perkhidmatan yang terikat pada 127.0.0.1 atau hanya IPv6 akan menolak klien yang menyelesaikan ke yang satu lagi.

Kemudian baca log perkhidmatan dan bukannya meneka. Permulaan semula selepas penyelenggaraan CA boleh gagal pada fail yang tidak boleh dibaca atau hilang dan tidak pernah mencapai keadaan mendengar, dan log menamakan fail itu. Itu kegagalan permulaan, pepijat yang berbeza daripada sijil yang ditolak.

UDP tiada handshake untuk ditolak

OpenVPN melalui UDP tidak membentuk sambungan dalam erti TCP, jadi tiada apa untuk ditolak pada masa connect. Di Linux, ralat yang ditunjukkan oleh soket UDP boleh datang daripada ICMP port-unreachable yang dijana oleh datagram terdahulu. halaman manual udp(7) menerangkan tingkah laku tak segerak itu.

Sebab itu klien UDP boleh mencetak penolakan semasa proses pelayan berjalan tetapi tidak terikat pada alamat yang dijangka.

Di mana CRL sebenarnya diperiksa

CRL dirujuk semasa handshake TLS, selepas pihak lawan mengemukakan sijilnya, dan hanya jika konfigurasi pelayan membenarkannya. Pilihan crl-verify OpenVPN menunjuk ke fail itu, dan kegagalan muncul dalam log pelayan sebagai ralat pengesahan yang menamakan sijil itu.

Klien yang dibatalkan oleh itu bersambung pada lapisan pengangkutan dan kemudian gagal dalam pengesahan. Pelayan sama, port sama, mesej sama sekali berbeza.

Periksa pengeluar dan tarikh sah CRL apabila anda sampai ke peringkat itu. CRL yang ditandatangani oleh CA yang salah, atau yang tamat tempoh sebelum klien bersambung, menghasilkan ralat pengesahan yang tiada kaitan dengan sijil klien itu sendiri.

Buku panduan ringkas untuk kali seterusnya

Sahkan pengangkutan dahulu: pendengar hadir, keluarga alamat betul, tembok api tidak menolak. Kemudian sahkan perkhidmatan mencapai keadaan mendengar dengan membaca log permulaan. Dan hanya selepas itu lihat ralat handshake untuk mesej pengesahan. Kekalkan urutan itu, kerana setiap langkah menyingkirkan satu kelas punca.

Catat pengangkutan, destinasi yang diselesaikan, port dan teks ralat yang tepat. Memasang semula klien memusnahkan bukti itu dan biasanya tidak mengubah apa-apa.