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 provera sertifikata se dešava kasnije, unutar rukovanja tunela. Vremensko poklapanje je kontekst, ne dokaz.

Dve provere razdvajaju slučajeve za manje od minuta, i nijedna od njih ne dira podešavanja poverenja.

Čitajte grešku na sloju koji ju je stvorio

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

Važi i obrnuto. Opozvani sertifikat proizvodi završenu TCP vezu i neuspelo rukovanje, koje se na serveru beleži kao greška provere.

TCP odbijanje: niko ne sluša

Za TCP proverite 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 umesto da odbacuje proizvodi istu poruku na strani klijenta, zato proveravate oboje.

Proverite i familiju adresa. Servis vezan za 127.0.0.1 ili samo za IPv6 odbiće klijenta koji se razrešava na drugu.

Zatim čitajte dnevnik servisa umesto da nagađate. Restart nakon održavanja CA može neuspeli 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 sertifikata.

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.

Gde se CRL zapravo proverava

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

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

Proverite izdavaoca CRL-a i datume važenja kada dođete do te faze. CRL potpisan pogrešnim CA, ili onaj koji je istekao pre nego što se klijent povezao, proizvodi greške provere koje nemaju nikakve veze sa klijentovim sopstvenim sertifikatom.

Kratak priručnik za sledeć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 provere. Držite taj redosled fiksnim, jer svaki korak isključuje celu klasu uzroka.

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