Bağlantı rədd edildi sertifikat problemi deyil: VPN üçün yoxlama planı
Rədd cavabı nəqliyyat qatının cavabıdır; sertifikat yoxlaması əl sıxma mərhələsində daha sonra baş verir. CA xidmətindən sonrakı səhər üçün sabit yoxlama sırası.
Müştəri CRL-i yenidən yaratdıqdan dərhal sonra bağlantının rədd edildiyini deyir, ona görə CRL günahkar görünür. Belə deyil. Rədd nəqliyyat qatının cavabıdır, sertifikat yoxlaması isə sonra, tunel əl sıxması içində baş verir. Vaxt uyğunluğu sübut deyil, kontekstdir.
İki yoxlama halları bir dəqiqədən az müddətdə ayırır və heç biri etimad parametrlərinə toxunmur.
Xətanı onu yaradan qatda oxuyun
connect-dən gələn ECONNREFUSED nəqliyyat cəhdinin rədd edildiyini bildirir: nəsə reset ilə cavab verdi və ya stek əlçatmaz port barədə məlumat verdi. Sertifikat problemi belə xəta yarada bilməz, çünki TLS əl sıxması nəqliyyat bağlantısı olmadan heç vaxt başlamır. Rədd görürsünüzsə, müştəri sertifikat təqdim etməyə çatmamışdır. Bu tək fakt ləğvi səbəb kimi istisna edir.
Əksi də doğrudur. Ləğv edilmiş sertifikat tamamlanmış TCP bağlantısı və uğursuz əl sıxma yaradır və serverdə yoxlama xətası kimi qeyd olunur.
TCP rəddi: heç kim dinləmir
TCP üçün nəzərdə tutulan instansın işlədiyini və profildəki ünvana və porta bağlandığını yoxlayın. ss -lntp dinləyiciləri göstərir və onların olmaması adi izahdır. Paketləri atmaq əvəzinə rədd edən firewall müştəri tərəfində eyni mesajı yaradır, buna görə hər ikisini yoxlayırsınız.
Ünvan ailəsini də yoxlayın. 127.0.0.1 ünvanına və ya yalnız IPv6-ya bağlanmış xidmət digərinə həll olunan müştərini rədd edəcək.
Sonra təxmin etmək əvəzinə xidmət jurnalını oxuyun. CA xidmətindən sonra yenidən başlatma oxunmayan və ya olmayan faylda uğursuz ola bilər və heç vaxt dinləmə vəziyyətinə çatmaz, jurnal isə faylın adını göstərir. Bu, başlatma xətasıdır, rədd edilmiş sertifikatdan fərqli bir problemdir.
UDP-nin rədd ediləsi əl sıxması yoxdur
UDP üzərindən OpenVPN TCP mənasında bağlantı qurmur, buna görə connect zamanı rədd ediləsi bir şey yoxdur. Linux-da UDP soketinin göstərdiyi xəta əvvəlki datagramın yaratdığı ICMP port-unreachable-dan gələ bilər. udp(7) man səhifəsi bu asinxron davranışı təsvir edir.
Buna görə UDP müştərisi server prosesi işlədiyi, lakin gözlənilən ünvana bağlanmadığı halda rədd çap edə bilər.
CRL həqiqətən harada yoxlanılır
CRL TLS əl sıxması zamanı, qarşı tərəf sertifikatını təqdim etdikdən sonra və yalnız server konfiqurasiyası buna icazə verdikdə sorğulanır. OpenVPN-in crl-verify seçimi fayla işarə edir və uğursuzluq server jurnalında sertifikatın adını çəkən yoxlama xətası kimi görünür.
Beləliklə, ləğv edilmiş müştəri nəqliyyat qatında qoşulur və sonra autentifikasiyada uğursuz olur. Eyni server, eyni port, tamamilə fərqli mesaj.
Həmin mərhələyə çatdıqda CRL-in verənini və etibarlılıq tarixlərini yoxlayın. Səhv CA tərəfindən imzalanmış və ya müştəri qoşulmazdan əvvəl vaxtı bitmiş CRL, müştərinin öz sertifikatı ilə heç bir əlaqəsi olmayan yoxlama xətaları yaradır.
Növbəti hal üçün qısa yoxlama planı
Əvvəlcə nəqliyyatı təsdiqləyin: dinləyici var, ünvan ailəsi düzgün, firewall rədd etmir. Sonra başlatma jurnalını oxuyaraq xidmətin dinləmə vəziyyətinə çatdığını təsdiqləyin. Sonra və yalnız bundan sonra yoxlama mesajları üçün əl sıxma xətalarına baxın. Bu sıranı sabit saxlayın, çünki hər addım bütöv bir səbəb sinfini aradan qaldırır.
Nəqliyyatı, həll olunmuş təyinatı, portu və dəqiq xəta mətnini yazın. Müştərinin yenidən quraşdırılması bu dəlili məhv edir və adətən heç nəyi dəyişmir.