Tilkopling avvist er ikkje eit sertifikatproblem: ei VPN-køyrebok

Klienten seier tilkopling avvist rett etter at du regenererte CRL-en, så CRL-en ser skuldig ut. Han er ikkje det. Avvising er eit svar frå transportlaget, og sertifikatvalidering skjer seinare, inne i tunnelhandtrykket. Tidspunktet er kontekst, ikkje prov.

To kontrollar skil sakene på under eitt minutt, og ingen av dei rører ved tillitsinnstillingane.

Les feilen på laget som laga han

ECONNREFUSED frå connect betyr at transportforsøket vart avvist: noko svara med ein reset, eller stakken rapporterte ein uoppnåeleg port. Eit sertifikatproblem kan ikkje lage den feilen, fordi TLS-handtrykket aldri startar utan ei transporttilkopling. Ser du ei avvising, kom klienten aldri langt nok til å leggje fram eit sertifikat. Den eine kjensgjerninga utelukkar tilbakekalling som årsak.

Det motsette gjeld òg. Eit tilbakekalla sertifikat gir ei fullført TCP-tilkopling og eit mislukka handtrykk, som blir logga på serveren som ein verifiseringsfeil.

TCP-avvising: ingen lyttar

For TCP, sjekk om den tiltenkte instansen køyrer og er bunden til adressa og porten i profilen. ss -lntp viser lyttarar, og fråværet av ein er den vanlege forklaringa. Ein brannmur som avviser i staden for å droppe, gir same meldinga på klientsida, difor sjekkar du begge.

Sjekk òg adressefamilien. Ein teneste bunden til 127.0.0.1 eller berre til IPv6 vil avvise ein klient som blir løyst til den andre.

Les deretter tenesteloggen i staden for å gjette. Ein omstart etter CA-vedlikehald kan feile på ei uleseleg eller manglande fil og aldri nå lyttetilstanden, og loggen namngir fila. Det er ein oppstartsfeil, ein annan feil enn eit avvist sertifikat.

UDP har ikkje handtrykk å avvise

OpenVPN over UDP etablerer ikkje ei tilkopling i TCP-forstand, så det er ingenting å avvise ved connect. På Linux kan ein feil som ein UDP-socket viser, kome frå ein ICMP port-unreachable generert av eit tidlegare datagram. man-sida udp(7) skildrar denne asynkrone åtferda.

Difor kan ein UDP-klient skrive ut ei avvising medan serverprosessen køyrer, men ikkje er bunden til den forventa adressa.

Kvar ein CRL faktisk blir sjekka

CRL-en blir konsultert under TLS-handtrykket, etter at motparten har lagt fram sertifikatet sitt, og berre om serverkonfigurasjonen tillèt det. OpenVPN sitt crl-verify-val peikar på fila, og ein feil blir vist i serverloggen som ein verifiseringsfeil som namngir sertifikatet.

Ein tilbakekalla klient koplar altså til på transportlaget og feilar deretter i autentiseringa. Same server, same port, heilt anna melding.

Sjekk utgivaren og gyldigheitsdatoane til CRL-en når du når det trinnet. Ein CRL signert av feil CA, eller ein som gjekk ut før klienten kopla til, gir verifiseringsfeil som ikkje har noko med klienten sitt eige sertifikat å gjere.

Ei kort køyrebok for neste gong

Stadfest først transporten: lyttar til stades, rett adressefamilie, brannmur som ikkje avviser. Stadfest deretter at tenesta nådde lyttetilstanden ved å lese oppstartsloggen. Og først då ser du på handtrykksfeil etter verifiseringsmeldingar. Hald den rekkjefølgja fast, fordi kvart steg utelukkar ein heil klasse årsaker.

Skriv ned transporten, den løyste destinasjonen, porten og den nøyaktige feilteksten. Ein reinstallasjon av klienten øydelegg beviset og endrar vanlegvis ingenting.