Conexiune refuzată nu este o problemă de certificat: un ghid VPN

Clientul spune că conexiunea a fost refuzată imediat după ce ați regenerat CRL-ul, așa că CRL-ul pare vinovat. Nu este. Refuzul este un răspuns al nivelului de transport, iar validarea certificatului are loc mai târziu, în handshake-ul tunelului. Momentele coincid, dar asta e context, nu dovadă.

Două verificări separă cazurile în mai puțin de un minut și niciuna nu atinge setările de încredere.

Citiți eroarea la nivelul care a produs-o

Un ECONNREFUSED de la connect înseamnă că încercarea de transport a fost refuzată: ceva a răspuns cu un reset sau stiva a raportat un port inaccesibil. O problemă de certificat nu poate produce acea eroare, pentru că handshake-ul TLS nu începe niciodată fără o conexiune de transport. Dacă vedeți un refuz, clientul nu a ajuns niciodată să prezinte un certificat. Acest singur fapt exclude revocarea ca cauză.

Este valabil și invers. Un certificat revocat produce o conexiune TCP completă și un handshake eșuat, înregistrat pe server ca eroare de verificare.

Refuz TCP: nimeni nu ascultă

Pentru TCP, verificați dacă instanța dorită rulează și este legată de adresa și portul din profil. ss -lntp arată ascultătorii, iar absența unuia este explicația obișnuită. Un firewall care refuză în loc să arunce produce același mesaj pe partea clientului, de aceea le verificați pe amândouă.

Verificați și familia de adrese. Un serviciu legat de 127.0.0.1 sau doar de IPv6 va refuza un client care se rezolvă către cealaltă.

Apoi citiți jurnalul serviciului în loc să ghiciți. O repornire după mentenanța CA poate eșua pe un fișier ilizibil sau lipsă și nu ajunge niciodată în starea de ascultare, iar jurnalul numește fișierul. Aceasta este o eroare de pornire, un defect diferit de un certificat refuzat.

UDP nu are un handshake de refuzat

OpenVPN prin UDP nu stabilește o conexiune în sensul TCP, deci nu este nimic de refuzat la momentul connect. Pe Linux, o eroare afișată de un socket UDP poate veni dintr-un ICMP port-unreachable generat de un datagramă anterioară. pagina de manual udp(7) descrie acest comportament asincron.

De aceea un client UDP poate afișa un refuz în timp ce procesul serverului rulează, dar nu este legat de adresa așteptată.

Unde este verificat de fapt un CRL

CRL-ul este consultat în timpul handshake-ului TLS, după ce partea cealaltă își prezintă certificatul, și numai dacă configurația serverului permite acest lucru. Opțiunea crl-verify a OpenVPN indică fișierul, iar o eroare apare în jurnalul serverului ca eroare de verificare care numește certificatul.

Așadar, un client revocat se conectează la nivelul de transport și apoi eșuează autentificarea. Același server, același port, mesaj complet diferit.

Verificați emitentul și datele de valabilitate ale CRL-ului când ajungeți în acea etapă. Un CRL semnat de CA greșită, sau unul care a expirat înainte ca clientul să se conecteze, produce erori de verificare care nu au nicio legătură cu certificatul clientului însuși.

Un ghid scurt pentru data viitoare

Confirmați mai întâi transportul: ascultător prezent, familie de adrese corectă, firewall care nu refuză. Apoi confirmați că serviciul a atins starea de ascultare citind jurnalul de pornire. Și abia apoi priviți erorile de handshake pentru mesaje de verificare. Păstrați această ordine fixă, pentru că fiecare pas elimină o întreagă clasă de cauze.

Notați transportul, destinația rezolvată, portul și textul exact al erorii. Reinstalarea clientului distruge acea dovadă și de obicei nu schimbă nimic.