Tagasi lükatud ühendus ei ole sertifikaadi probleem: VPN-i tegevusjuhend

Klient ütleb, et ühendus lükati tagasi kohe pärast CRL-i uuesti genereerimist, seega tundub CRL süüdi olevat. Ei ole. Tagasilükkamine on transpordikihi vastus ja sertifikaadi valideerimine toimub hiljem, tunnelis käepigistuse sees. Ajastus on kontekst, mitte tõestus.

Kaks kontrolli eristavad juhtumeid alla minuti ja kumbki neist ei puuduta usalduse seadeid.

Lugege viga sellel kihil, mis selle tekitas

ECONNREFUSED connectist tähendab, et transpordikatse lükati tagasi: miski vastas resetiga või pinu teatas kättesaamatust pordist. Sertifikaadi probleem ei saa seda viga tekitada, sest TLS-i käepigistus ei alga kunagi ilma transpordiühenduseta. Kui näete tagasilükkamist, ei jõudnud klient kunagi nii kaugele, et sertifikaati esitada. See üks fakt välistab tühistamise põhjusena.

Kehtib ka vastupidine. Tühistatud sertifikaat tekitab lõpetatud TCP-ühenduse ja ebaõnnestunud käepigistuse, mis logitakse serveris valideerimisveana.

TCP tagasilükkamine: keegi ei kuula

TCP puhul kontrollige, kas kavandatud eksemplar töötab ja on seotud profiilis oleva aadressi ja pordiga. ss -lntp näitab kuulajaid ja nende puudumine on tavaline seletus. Tulemüür, mis lükkab tagasi, mitte ei viska ära, tekitab kliendi poolel sama sõnumi, seepärast kontrollite mõlemat.

Kontrollige ka aadressiperekonda. Teenus, mis on seotud 127.0.0.1 või ainult IPv6-ga, lükkab tagasi kliendi, mis lahendub teisele.

Seejärel lugege teenuse logi, mitte ärge oletage. Taaskäivitamine pärast CA hooldust võib ebaõnnestuda loetamatu või puuduva faili tõttu ega jõua kunagi kuulamise olekusse, ja logi nimetab faili. See on käivitustõrge, teistsugune viga kui tagasi lükatud sertifikaat.

UDP-l pole käepigistust, mida tagasi lükata

OpenVPN üle UDP ei loo ühendust TCP mõttes, seega connect'i ajal pole midagi tagasi lükata. Linuxis võib UDP-pesast ilmuv viga pärineda varasema datagrammi tekitatud ICMP port-unreachable'ist. udp(7) manuaalileht kirjeldab seda asünkroonset käitumist.

Seepärast võib UDP klient välja printida tagasilükkamise, samal ajal kui serveriprotsess töötab, kuid ei ole seotud oodatud aadressiga.

Kus CRL-i tegelikult kontrollitakse

CRL-i konsulteeritakse TLS-i käepigistuse ajal, pärast seda kui vastaspool esitab oma sertifikaadi, ja ainult siis, kui serveri konfiguratsioon seda lubab. OpenVPN-i valik crl-verify osutab failile ja tõrge ilmub serveri logis valideerimisveana, mis nimetab sertifikaati.

Tühistatud klient ühendub seega transpordikihil ja ebaõnnestub seejärel autentimises. Sama server, sama port, täiesti teistsugune sõnum.

Kontrollige CRL-i väljaandjat ja kehtivuskuupäevi, kui sellesse etappi jõuate. Vale CA poolt allkirjastatud CRL või selline, mis aegus enne kliendi ühendumist, tekitab valideerimisvigu, millel pole kliendi enda sertifikaadiga mingit seost.

Lühike tegevusjuhend järgmiseks korraks

Kinnitage esmalt transport: kuulaja on olemas, õige aadressiperekond, tulemüür ei lükka tagasi. Seejärel kinnitage käivituslogi lugedes, et teenus jõudis kuulamisolekusse. Ja alles siis vaadake käepigistuse vigu valideerimissõnumite otsimiseks. Hoidke see järjekord fikseerituna, sest iga samm välistab terve põhjuste klassi.

Kirjutage üles transport, lahendatud sihtkoht, port ja täpne veatext. Kliendi uuesti paigaldamine hävitab selle tõendi ja tavaliselt ei muuda midagi.