Odbijena veza nije problem certifikata: priručnik za VPN

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

Dvije provjere razdvajaju slučajeve u 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 stog 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. Opozvani certifikat proizvodi završenu TCP vezu i neuspjelo rukovanje, koje se na poslužitelju bilježi kao greška provjere.

TCP odbijanje: nitko ne sluša

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

Provjerite i obitelj adresa. Usluga vezana uz 127.0.0.1 ili samo uz IPv6 odbit će klijenta koji se razrješava na drugu.

Zatim čitajte dnevnik usluge umjesto da nagađate. Ponovno pokretanje 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 što odbiti. Na Linuxu greška koju prikaže UDP socket može doći od ICMP port-unreachable kojeg je generirao raniji datagram. stranica priručnika udp(7) opisuje to asinkrono ponašanje.

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

Gdje se CRL zapravo provjerava

CRL se konzultira tijekom TLS rukovanja, nakon što druga strana predstavi svoj certifikat, i to samo ako konfiguracija poslužitelja to omogućuje. OpenVPN opcija crl-verify pokazuje na datoteku, a neuspjeh se u dnevniku poslužitelja pojavljuje kao greška provjere koja imenuje certifikat.

Opozvani klijent se dakle povezuje na transportnom sloju i zatim pada na autentifikaciji. Isti poslužitelj, isti port, posve drugačija poruka.

Provjerite izdavatelja CRL-a i datume valjanosti 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šač prisutan, ispravna obitelj adresa, vatrozid ne odbija. Zatim potvrdite da je usluga dosegnula stanje slušanja čitajući dnevnik pokretanja. Pa tek onda pogledajte 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 točan tekst greške. Ponovna instalacija klijenta uništava taj dokaz i obično ništa ne mijenja.