Forbindelse afvist er ikke et certifikatproblem: en VPN-kørebog

Klienten siger forbindelse afvist lige efter du genoprettede CRL’en, så CRL’en ser skyldig ud. Det er den ikke. Afvisning er et svar fra transportlaget, og certifikatvalidering sker senere, inde i tunnelhåndtrykket. Tidspunktet er kontekst, ikke bevis.

To kontroller adskiller sagerne på under et minut, og ingen af dem rører ved tillidsindstillingerne.

Læs fejlen på det lag, der producerede den

ECONNREFUSED fra connect betyder, at transportforsøget blev afvist: noget svarede med et reset, eller stakken rapporterede en uopnåelig port. Et certifikatproblem kan ikke frembringe den fejl, fordi TLS-håndtrykket aldrig starter uden en transportforbindelse. Ser du en afvisning, nåede klienten aldrig langt nok til at fremvise et certifikat. Den ene kendsgerning udelukker tilbagekaldelse som årsag.

Det omvendte gælder også. Et tilbagekaldt certifikat giver en fuldført TCP-forbindelse og et mislykket håndtryk, som på serveren logges som en verifikationsfejl.

TCP-afvisning: ingen lytter

For TCP skal du kontrollere, om den tilsigtede instans kører og er bundet til adressen og porten i profilen. ss -lntp viser lyttere, og fraværet af en er den sædvanlige forklaring. En firewall, der afviser i stedet for at droppe, giver den samme meddelelse på klientsiden, og derfor tjekker du begge.

Kontrollér også adressefamilien. En tjeneste bundet til 127.0.0.1 eller kun til IPv6 vil afvise en klient, der opløses til den anden.

Læs derefter tjenestens log i stedet for at gætte. En genstart efter CA-vedligeholdelse kan fejle på en ulæselig eller manglende fil og aldrig nå lyttetilstanden, og loggen navngiver filen. Det er en opstartsfejl, en anden fejl end et afvist certifikat.

UDP har intet håndtryk at afvise

OpenVPN over UDP etablerer ikke en forbindelse i TCP’s forstand, så der er intet at afvise på connect-tidspunktet. På Linux kan en fejl, som en UDP-socket viser, komme fra en ICMP port-unreachable genereret af et tidligere datagram. man-siden udp(7) beskriver den asynkrone adfærd.

Derfor kan en UDP-klient udskrive en afvisning, mens serverprocessen kører, men ikke er bundet til den forventede adresse.

Hvor en CRL faktisk kontrolleres

CRL’en konsulteres under TLS-håndtrykket, efter at modparten har fremvist sit certifikat, og kun hvis serverkonfigurationen tillader det. OpenVPN’s crl-verify-indstilling peger på filen, og en fejl vises i serverloggen som en verifikationsfejl, der navngiver certifikatet.

En tilbagekaldt klient forbinder altså på transportlaget og fejler derefter i godkendelsen. Samme server, samme port, helt anden meddelelse.

Kontrollér CRL’ens udsteder og gyldighedsdatoer, når du når det trin. En CRL signeret af den forkerte CA, eller en der udløb før klienten forbandt, giver verifikationsfejl, der intet har at gøre med klientens eget certifikat.

En kort kørebog til næste gang

Bekræft først transporten: lytter til stede, korrekt adressefamilie, firewall afviser ikke. Bekræft derefter, at tjenesten nåede sin lyttetilstand ved at læse opstartsloggen. Se så, og først så, på håndtryksfejl efter verifikationsmeddelelser. Hold den rækkefølge fast, fordi hvert trin udelukker en hel klasse af årsager.

Skriv transporten, den opløste destination, porten og den præcise fejltekst ned. En geninstallation af klienten ødelægger det bevis og ændrer normalt intet.