Koneksi ditolak bukan masalah sertifikat: buku panduan VPN

Klien bilang koneksi ditolak tepat setelah Anda membuat ulang CRL, jadi CRL tampak bersalah. Tidak. Penolakan adalah jawaban lapisan transport, dan validasi sertifikat terjadi kemudian, di dalam handshake tunnel. Waktunya adalah konteks, bukan bukti.

Dua pemeriksaan memisahkan kedua kasus dalam waktu kurang dari satu menit, dan keduanya tidak menyentuh pengaturan kepercayaan.

Baca galat pada lapisan yang menghasilkannya

ECONNREFUSED dari connect berarti upaya transport ditolak: sesuatu menjawab dengan reset, atau stack melaporkan port yang tidak terjangkau. Masalah sertifikat tidak dapat menghasilkan galat itu, karena handshake TLS tidak pernah dimulai tanpa koneksi transport. Jika Anda melihat penolakan, klien tidak pernah cukup jauh untuk menyajikan sertifikat. Fakta tunggal itu menyingkirkan pencabutan sebagai penyebab.

Berlaku juga sebaliknya. Sertifikat yang dicabut menghasilkan koneksi TCP yang selesai dan handshake yang gagal, tercatat di server sebagai galat verifikasi.

Penolakan TCP: tidak ada yang mendengarkan

Untuk TCP, periksa apakah instans yang dimaksud berjalan dan terikat ke alamat serta port di profil. ss -lntp menampilkan pendengar, dan tidak adanya salah satunya adalah penjelasan yang biasa. Firewall yang menolak alih-alih membuang menghasilkan pesan yang sama di sisi klien, karena itu Anda memeriksa keduanya.

Periksa juga keluarga alamat. Layanan yang terikat ke 127.0.0.1 atau hanya ke IPv6 akan menolak klien yang melakukan resolusi ke yang lain.

Lalu baca log layanan alih-alih menebak. Mulai ulang setelah pemeliharaan CA bisa gagal pada berkas yang tidak terbaca atau hilang dan tidak pernah mencapai status mendengarkan, dan log menyebutkan berkasnya. Itu kegagalan startup, bug yang berbeda dari sertifikat yang ditolak.

UDP tidak punya handshake untuk ditolak

OpenVPN melalui UDP tidak membentuk koneksi dalam arti TCP, jadi tidak ada yang bisa ditolak saat connect. Di Linux, galat yang ditampilkan soket UDP bisa berasal dari ICMP port-unreachable yang dihasilkan datagram sebelumnya. halaman manual udp(7) menjelaskan perilaku asinkron itu.

Karena itu klien UDP dapat mencetak penolakan saat proses server berjalan tetapi tidak terikat ke alamat yang diharapkan.

Di mana CRL sebenarnya diperiksa

CRL dikonsultasikan selama handshake TLS, setelah pihak lawan menyajikan sertifikatnya, dan hanya jika konfigurasi server mengizinkannya. Opsi crl-verify OpenVPN menunjuk ke berkas, dan kegagalan muncul di log server sebagai galat verifikasi yang menyebutkan sertifikat.

Klien yang dicabut karena itu terhubung di lapisan transport lalu gagal pada autentikasi. Server sama, port sama, pesan sangat berbeda.

Periksa penerbit dan tanggal berlaku CRL saat Anda mencapai tahap itu. CRL yang ditandatangani CA yang salah, atau yang kedaluwarsa sebelum klien terhubung, menghasilkan galat verifikasi yang tidak ada hubungannya dengan sertifikat klien itu sendiri.

Buku panduan singkat untuk kejadian berikutnya

Pastikan dulu transportnya: pendengar ada, keluarga alamat benar, firewall tidak menolak. Lalu pastikan layanan mencapai status mendengarkan dengan membaca log startup. Dan baru setelah itu lihat galat handshake untuk pesan verifikasi. Pertahankan urutan itu, karena setiap langkah menyingkirkan satu kelas penyebab.

Catat transport, tujuan hasil resolusi, port, dan teks galat yang tepat. Memasang ulang klien menghancurkan bukti itu dan biasanya tidak mengubah apa pun.