Avvist tilkobling er ikke et sertifikatproblem: en VPN-kjørebok for drift

Klienten melder avvist tilkobling like etter at du genererte CRL-en på nytt, så CRL-en virker skyldig. Den er ikke det. Avvisning er et svar fra transportlaget, og sertifikatvalidering skjer senere, inne i tunnelens håndtrykk. Tidspunktet er kontekst, ikke bevis.

To kontroller skiller tilfellene på under ett minutt, og ingen av dem berører tillitsinnstillingene.

Les feilen på det laget som skapte den

ECONNREFUSED fra connect betyr at transportforsøket ble avvist: noe svarte med reset, eller stakken rapporterte en port som ikke kan nås. Et sertifikatproblem kan ikke gi den feilen, fordi TLS-håndtrykket aldri starter uten en transportforbindelse. Ser du en avvisning, nådde klienten aldri fram til å presentere et sertifikat. Den ene opplysningen utelukker tilbakekalling som årsak.

Det motsatte gjelder også. Et tilbakekalt sertifikat gir en fullført TCP-forbindelse og et mislykket håndtrykk, som føres i serverloggen som en verifiseringsfeil.

TCP-avvisning: ingen lytter på porten

For TCP må du kontrollere om den tiltenkte instansen kjører og er bundet til adressen og porten i profilen. ss -lntp viser lyttere, og at ingen finnes er den vanlige forklaringen. En brannmur som avviser i stedet for å forkaste, gir samme melding på klientsiden, derfor kontrollerer du begge.

Kontroller også adressefamilien. En tjeneste bundet til 127.0.0.1 eller bare IPv6 vil avvise en klient som løses til den andre.

Deretter leser du tjenesteloggen i stedet for å gjette. En omstart etter CA-vedlikehold kan feile på en fil som ikke kan leses eller mangler, og aldri nå lyttetilstanden, og loggen navngir filen. Det er en oppstartsfeil, en annen feil enn et avvist sertifikat.

UDP har ikke noe håndtrykk å avvise

OpenVPN over UDP oppretter ikke en forbindelse i TCP-forstand, så det er ingenting å avvise ved connect. På Linux kan en feil som en UDP-socket viser, komme fra en ICMP port-unreachable som et tidligere datagram har generert. man-siden udp(7) beskriver denne asynkrone oppførselen.

Derfor kan en UDP-klient skrive ut en avvisning mens serverprosessen kjører, men ikke er bundet til den forventede adressen.

Hvor CRL-en faktisk blir kontrollert

CRL-en konsulteres under TLS-håndtrykket, etter at motparten har presentert sertifikatet sitt, og bare dersom serveroppsettet tillater det. OpenVPN-valget crl-verify peker på filen, og en feil vises i serverloggen som en verifiseringsfeil som navngir sertifikatet.

En tilbakekalt klient kobler altså til på transportlaget og feiler deretter i autentiseringen. Samme server, samme port, helt annen melding.

Kontroller CRL-ens utsteder og gyldighetsdatoer når du kommer til det trinnet. En CRL som er signert av feil CA, eller en som utløp før klienten koblet til, gir verifiseringsfeil som ikke har noe med klientens eget sertifikat å gjøre.

Kort kjørebok for neste hendelse

Bekreft transporten først: lytter til stede, riktig adressefamilie, brannmur som ikke avviser. Deretter bekrefter du at tjenesten nådde lyttetilstanden ved å lese oppstartsloggen. Og først da ser du på håndtrykksfeil etter verifiseringsmeldinger. Hold rekkefølgen fast, fordi hvert trinn utelukker en hel klasse av årsaker.

Skriv ned transporten, den oppløste destinasjonen, porten og den nøyaktige feilteksten. Ny installasjon av klienten ødelegger beviset og endrer vanligvis ingenting.