Odbijena veza nije problem sertifikata: priručnik za VPN

Klijent kaže da je veza odbijena odmah nakon što ste regenerisali CRL, pa CRL izgleda kriv. Nije. Odbijanje je odgovor transportnog sloja, a provjera certifikata se dešava kasnije, unutar rukovanja tunela. Vremensko poklapanje je kontekst, ne dokaz.

Dvije provjere razdvajaju slučajeve za manje od minute, i nijedna od njih ne dira postavke povjerenja.

Čitajte grešku na sloju koji ju je proizveo

ECONNREFUSED iz connect znači da je transportni pokušaj odbijen: nešto je odgovorilo resetom, ili je stek prijavio nedostupan port. Problem s certifikatom ne može proizvesti tu grešku, jer TLS rukovanje nikada ne počinje bez transportne veze. Ako vidite odbijanje, klijent nikada nije stigao dovoljno daleko da predstavi certifikat. Ta jedna činjenica isključuje opoziv kao uzrok.

Vrijedi i obrnuto. Opozvan certifikat proizvodi završenu TCP vezu i neuspjelo rukovanje, koje se na serveru bilježi kao greška provjere.

TCP odbijanje: niko ne sluša

Za TCP provjerite da li predviđena instanca radi i da li je vezana za adresu i port iz profila. ss -lntp prikazuje slušaoce, a njihovo odsustvo je uobičajeno objašnjenje. Firewall koji odbija umjesto da odbacuje proizvodi istu poruku na strani klijenta, zato provjeravate oboje.

Provjerite i familiju adresa. Servis vezan za 127.0.0.1 ili samo za IPv6 odbit će klijenta koji se razrješava na drugu.

Zatim čitajte dnevnik servisa umjesto da nagađate. Restart nakon održavanja CA može neuspjeti na nečitljivoj ili nedostajućoj datoteci i nikada ne doći do stanja slušanja, a dnevnik imenuje datoteku. To je greška pri pokretanju, drugačiji problem od odbijenog certifikata.

UDP nema rukovanje koje bi odbio

OpenVPN preko UDP-a ne uspostavlja vezu u TCP smislu, pa se pri connect nema šta odbiti. Na Linuxu greška koju prikaže UDP socket može doći od ICMP port-unreachable kojeg je generisao raniji datagram. stranica priručnika udp(7) opisuje to asinhrono ponašanje.

Zato UDP klijent može ispisati odbijanje dok serverski proces radi, ali nije vezan za očekivanu adresu.

Gdje se CRL zapravo provjerava

CRL se konsultuje tokom TLS rukovanja, nakon što druga strana predstavi svoj certifikat, i to samo ako serverska konfiguracija to omogućava. OpenVPN opcija crl-verify pokazuje na datoteku, a neuspjeh se u serverskom dnevniku pojavljuje kao greška provjere koja imenuje certifikat.

Opozvan klijent se dakle povezuje na transportnom sloju i zatim pada na autentifikaciji. Isti server, isti port, potpuno drugačija poruka.

Provjerite izdavaoca CRL-a i datume važenja kada dođete do te faze. CRL potpisan pogrešnim CA, ili onaj koji je istekao prije nego što se klijent povezao, proizvodi greške provjere koje nemaju nikakve veze s klijentovim vlastitim certifikatom.

Kratki priručnik za sljedeći put

Prvo potvrdite transport: slušalac prisutan, ispravna familija adresa, firewall ne odbija. Zatim potvrdite da je servis dostigao stanje slušanja čitajući dnevnik pokretanja. Pa tek onda gledajte greške rukovanja u potrazi za porukama provjere. Držite taj redoslijed fiksnim, jer svaki korak isključuje cijelu klasu uzroka.

Zapišite transport, razriješeno odredište, port i tačan tekst greške. Ponovna instalacija klijenta uništava taj dokaz i obično ništa ne mijenja.