Tilkobling avvist er ikke et sertifikatproblem: en VPN-kjørebok

Klienten sier tilkobling avvist rett etter at du regenererte CRL-en, så CRL-en ser skyldig ut. Den er ikke det. Avvisning er et svar fra transportlaget, og sertifikatvalidering skjer senere, inne i tunnelhåndtrykket. Tidspunktet er kontekst, ikke bevis.

To kontroller skiller sakene på under ett minutt, og ingen av dem rører ved tillitsinnstillingene.

Les feilen på laget som produserte den

ECONNREFUSED fra connect betyr at transportforsøket ble avvist: noe svarte med en reset, eller stakken rapporterte en uoppnåelig port. Et sertifikatproblem kan ikke produsere den feilen, fordi TLS-håndtrykket aldri starter uten en transportforbindelse. Ser du en avvisning, kom klienten aldri langt nok til å legge fram et sertifikat. Det ene faktumet utelukker tilbakekalling som årsak.

Det motsatte gjelder også. Et tilbakekalt sertifikat gir en fullført TCP-forbindelse og et mislykket håndtrykk, som logges på serveren som en verifiseringsfeil.

TCP-avvisning: ingen lytter

For TCP, sjekk om den tiltenkte instansen kjører og er bundet til adressen og porten i profilen. ss -lntp viser lyttere, og fraværet av en er den vanlige forklaringen. En brannmur som avviser i stedet for å droppe, gir samme melding på klientsiden, derfor sjekker du begge.

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

Les deretter tjenesteloggen i stedet for å gjette. En omstart etter CA-vedlikehold kan feile på en uleselig eller manglende fil og aldri nå lyttetilstanden, og loggen navngir filen. Det er en oppstartsfeil, en annen feil enn et avvist sertifikat.

UDP har ingen håndtrykk å avvise

OpenVPN over UDP etablerer 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 generert av et tidligere datagram. 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 en CRL faktisk sjekkes

CRL-en konsulteres under TLS-håndtrykket, etter at motparten har lagt fram sertifikatet sitt, og bare hvis serverkonfigurasjonen tillater det. OpenVPNs crl-verify-valg 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.

Sjekk CRL-ens utsteder og gyldighetsdatoer når du når det trinnet. En CRL 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.

En kort kjørebok for neste gang

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

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