Verbinding geweier is nie 'n sertifikaatprobleem nie: 'n VPN-draaiboek

Die kliënt sê verbinding geweier net ná jy die CRL hergenereer het, so die CRL lyk skuldig. Dit is nie. Weiering is 'n antwoord van die vervoerlaag, en sertifikaatvalidering gebeur later, binne die tonnel-handskud. Die tydsberekening is konteks, nie bewys nie.

Twee kontroles skei die gevalle in minder as 'n minuut, en nie een van hulle raak aan vertrouensinstellings nie.

Lees die fout op die laag wat dit veroorsaak het

ECONNREFUSED van connect beteken die vervoerpoging is verwerp: iets het met 'n reset geantwoord, of die stapel het 'n onbereikbare poort gerapporteer. 'n Sertifikaatprobleem kan nie daardie fout lewer nie, want die TLS-handskud begin nooit sonder 'n vervoerverbinding nie. As jy 'n weiering sien, het die kliënt nooit ver genoeg gekom om 'n sertifikaat voor te lê nie. Daardie enkele feit sluit herroeping as oorsaak uit.

Die omgekeerde geld ook. 'n Herroepe sertifikaat lewer 'n voltooide TCP-verbinding en 'n mislukte handskud, wat op die bediener as 'n verifikasiefout aangeteken word.

TCP-weiering: niemand luister nie

Vir TCP, kyk of die beoogde instansie loop en aan die adres en poort in die profiel gebind is. ss -lntp wys luisteraars, en die afwesigheid van een is die gewone verklaring. 'n Brandmuur wat verwerp eerder as om te laat val, lewer dieselfde boodskap aan die kliëntekant, en daarom kyk jy na albei.

Kyk ook na die adresfamilie. 'n Diens wat aan 127.0.0.1 of slegs aan IPv6 gebind is, sal 'n kliënt weier wat na die ander een oplos.

Lees dan die dienslog eerder as om te raai. 'n Herstart ná CA-onderhoud kan misluk op 'n onleesbare of ontbrekende lêer en nooit die luistertoestand bereik nie, en die log noem die lêer. Dit is 'n opstartfout, 'n ander fout as 'n verwerpte sertifikaat.

UDP het geen handskud om te weier nie

OpenVPN oor UDP vestig nie 'n verbinding in die TCP-sin nie, so daar is niks om by connect te weier nie. Op Linux kan 'n fout wat deur 'n UDP-sok weerspieël word, kom van 'n ICMP port-unreachable wat deur 'n vroeëre datagram gegenereer is. Die udp(7)-manbladsy beskryf daardie asinchrone gedrag.

Dit is hoekom 'n UDP-kliënt 'n weiering kan druk terwyl die bedienerproses loop maar nie aan die verwagte adres gebind is nie.

Waar 'n CRL werklik nagegaan word

Die CRL word tydens die TLS-handskud geraadpleeg, nadat die eweknie sy sertifikaat voorgelê het, en slegs as die bedienerkonfigurasie dit aanskakel. OpenVPN se crl-verify-opsie wys na die lêer, en 'n mislukking verskyn in die bedienerlog as 'n verifikasiefout wat die sertifikaat noem.

'n Herroepe kliënt verbind dus op die vervoerlaag en faal dan in verifikasie. Dieselfde bediener, dieselfde poort, heeltemal ander boodskap.

Kontroleer die CRL se uitreiker en geldigheidsdatums wanneer jy daardie stadium bereik. 'n CRL wat deur die verkeerde CA onderteken is, of een wat verval het voordat die kliënt verbind het, lewer verifikasiefoute wat niks met die kliënt se eie sertifikaat te doen het nie.

'n Kort draaiboek vir die volgende keer

Bevestig eers die vervoer: luisteraar teenwoordig, korrekte adresfamilie, brandmuur wat nie verwerp nie. Bevestig dan dat die diens sy luistertoestand bereik het deur die opstartlog te lees. Kyk dan, en eers dan, na handskudfoute vir verifikasieboodskappe. Hou daardie volgorde vas, want elke stap skakel 'n hele klas oorsake uit.

Skryf die vervoer, die opgeloste bestemming, die poort en die presiese foutteks neer. 'n Herinstallasie van die kliënt vernietig daardie bewyse en verander gewoonlik niks.