Lidhja e refuzuar nuk është problem certifikate: udhëzues VPN

Klienti thotë lidhja u refuzua menjëherë pasi rigjeneruat CRL-në, prandaj CRL-ja duket fajtore. Nuk është. Refuzimi është përgjigje e shtresës së transportit, dhe validimi i certifikatës ndodh më vonë, brenda handshake-ut të tunelit. Koha është kontekst, jo provë.

Dy kontrolle i ndajnë rastet në më pak se një minutë, dhe asnjëra prej tyre nuk prek cilësimet e besimit.

Lexoni gabimin në shtresën që e prodhoi

ECONNREFUSED nga connect do të thotë se përpjekja e transportit u refuzua: diçka u përgjigj me reset, ose staku raportoi një port të paarritshëm. Një problem certifikate nuk mund ta prodhojë atë gabim, sepse handshake-u TLS nuk fillon kurrë pa një lidhje transporti. Nëse shihni refuzim, klienti nuk arriti kurrë mjaftueshëm për të paraqitur një certifikatë. Ky fakt i vetëm përjashton revokimin si shkak.

Vlen edhe e kundërta. Një certifikatë e revokuar prodhon një lidhje TCP të plotë dhe një handshake të dështuar, që regjistrohet në server si gabim verifikimi.

Refuzimi TCP: askush nuk dëgjon

Për TCP, kontrolloni nëse instanca e synuar po funksionon dhe është e lidhur me adresën dhe portin në profil. ss -lntp tregon dëgjuesit, dhe mungesa e njërit është shpjegimi i zakonshëm. Një firewall që refuzon në vend që të hedhë poshtë prodhon të njëjtin mesazh në anën e klientit, prandaj kontrolloni të dyja.

Kontrolloni edhe familjen e adresave. Një shërbim i lidhur me 127.0.0.1 ose vetëm me IPv6 do të refuzojë një klient që zgjidhet në tjetrën.

Më pas lexoni regjistrin e shërbimit në vend që të hamendësoni. Një rinisje pas mirëmbajtjes së CA mund të dështojë në një skedar të palexueshëm ose që mungon dhe të mos arrijë kurrë gjendjen e dëgjimit, dhe regjistri e emërton skedarin. Ky është një dështim nisjeje, një gabim tjetër nga një certifikatë e refuzuar.

UDP nuk ka handshake për të refuzuar

OpenVPN mbi UDP nuk vendos një lidhje në kuptimin TCP, prandaj në momentin e connect nuk ka asgjë për të refuzuar. Në Linux, një gabim i shfaqur nga një socket UDP mund të vijë nga një ICMP port-unreachable i krijuar nga një datagram i mëparshëm. faqja e manualit udp(7) përshkruan këtë sjellje asinkrone.

Prandaj një klient UDP mund të shtypë një refuzim ndërsa procesi i serverit po funksionon, por nuk është i lidhur me adresën e pritur.

Ku kontrollohet në të vërtetë një CRL

CRL-ja konsultohet gjatë handshake-ut TLS, pasi pala tjetër paraqet certifikatën e vet, dhe vetëm nëse konfigurimi i serverit e lejon. Opsioni crl-verify i OpenVPN tregon skedarin, dhe një dështim shfaqet në regjistrin e serverit si gabim verifikimi që emërton certifikatën.

Një klient i revokuar, pra, lidhet në shtresën e transportit dhe më pas dështon në autentikim. I njëjti server, i njëjti port, mesazh krejt tjetër.

Kontrolloni lëshuesin dhe datat e vlefshmërisë së CRL-së kur të arrini në atë fazë. Një CRL e nënshkruar nga CA e gabuar, ose një që skadoi para se klienti të lidhej, prodhon gabime verifikimi që nuk kanë asnjë lidhje me certifikatën e vetë klientit.

Një udhëzues i shkurtër për herën tjetër

Konfirmoni fillimisht transportin: dëgjues i pranishëm, familje e saktë adresash, firewall që nuk refuzon. Më pas konfirmoni se shërbimi arriti gjendjen e dëgjimit duke lexuar regjistrin e nisjes. Dhe vetëm atëherë shikoni gabimet e handshake-ut për mesazhe verifikimi. Mbajeni atë rend fiks, sepse çdo hap eliminon një klasë të tërë shkaqesh.

Shkruani transportin, destinacionin e zgjidhur, portin dhe tekstin e saktë të gabimit. Riinstalimi i klientit e shkatërron atë provë dhe zakonisht nuk ndryshon asgjë.