Atmestas ryšys nėra sertifikato problema: VPN veiksmų vadovas

Klientas sako, kad ryšys atmestas iškart po to, kai atkūrėte CRL, todėl CRL atrodo kaltas. Taip nėra. Atmetimas yra transporto sluoksnio atsakymas, o sertifikato tikrinimas vyksta vėliau, tunelio rankos paspaudime. Laiko sutapimas yra kontekstas, o ne įrodymas.

Dvi patikros atskiria atvejus per mažiau nei minutę, ir nė viena jų neliečia pasitikėjimo nustatymų.

Skaitykite klaidą tame sluoksnyje, kuris ją sukūrė

ECONNREFUSED iš connect reiškia, kad transporto bandymas buvo atmestas: kažkas atsakė reset, arba stekas pranešė apie nepasiekiamą prievadą. Sertifikato problema negali sukelti šios klaidos, nes TLS rankos paspaudimas niekada neprasideda be transporto ryšio. Jei matote atmetimą, klientas niekada nepasiekė etapo, kuriame pateikiamas sertifikatas. Šis vienas faktas pašalina atšaukimą kaip priežastį.

Galioja ir priešingai. Atšauktas sertifikatas sukuria užbaigtą TCP ryšį ir nepavykusį rankos paspaudimą, kuris serveryje registruojamas kaip tikrinimo klaida.

TCP atmetimas: niekas neklauso

TCP atveju patikrinkite, ar numatyta instancija veikia ir ar susieta su profilio adresu ir prievadu. ss -lntp rodo klausytojus, o jų nebuvimas yra įprastas paaiškinimas. Ugniausienė, kuri atmeta, o ne numeta, sukuria tą pačią žinutę kliento pusėje, todėl tikrinate abu.

Patikrinkite ir adresų šeimą. Paslauga, susieta su 127.0.0.1 arba tik su IPv6, atmes klientą, kuris sprendžiamas į kitą.

Tada skaitykite paslaugos žurnalą, o ne spėliokite. Paleidimas iš naujo po CA priežiūros gali nepavykti dėl neperskaitomo ar trūkstamo failo ir niekada nepasiekti klausymosi būsenos, o žurnale nurodomas failas. Tai paleidimo klaida, kitokia klaida nei atmestas sertifikatas.

UDP neturi rankos paspaudimo, kurį būtų galima atmesti

OpenVPN per UDP neužmezga ryšio TCP prasme, todėl connect metu nėra ko atmesti. Linux sistemoje UDP lizdo rodoma klaida gali kilti iš ankstesnio datagramos sukurto ICMP port-unreachable. udp(7) vadovo puslapis aprašo šį asinchroninį elgesį.

Todėl UDP klientas gali išspausdinti atmetimą, kai serverio procesas veikia, bet nėra susietas su laukiamu adresu.

Kur CRL iš tikrųjų tikrinamas

CRL konsultuojamas TLS rankos paspaudimo metu, po to kai kita pusė pateikia savo sertifikatą, ir tik jei serverio konfigūracija tai leidžia. OpenVPN parinktis crl-verify nurodo failą, o nesėkmė serverio žurnale pasirodo kaip tikrinimo klaida, nurodanti sertifikatą.

Taigi atšauktas klientas prisijungia transporto sluoksnyje ir tada nepavyksta autentifikacija. Tas pats serveris, tas pats prievadas, visiškai kitokia žinutė.

Kai pasieksite tą etapą, patikrinkite CRL išdavėją ir galiojimo datas. CRL, pasirašytas netinkamo CA, arba pasibaigęs prieš kliento prisijungimą, sukuria tikrinimo klaidas, kurios neturi nieko bendra su paties kliento sertifikatu.

Trumpas veiksmų vadovas kitam kartui

Pirmiausia patvirtinkite transportą: klausytojas yra, teisinga adresų šeima, ugniausienė neatmeta. Tada patvirtinkite, kad paslauga pasiekė klausymosi būseną, perskaitę paleidimo žurnalą. Ir tik tada žiūrėkite rankos paspaudimo klaidas, ieškodami tikrinimo pranešimų. Laikykitės šios tvarkos, nes kiekvienas žingsnis pašalina visą priežasčių klasę.

Užrašykite transportą, išspręstą paskirties vietą, prievadą ir tikslią klaidos tekstą. Kliento perdiegimas sunaikina šį įrodymą ir paprastai nieko nekeičia.