Verbinding geweigerd is geen certificaatprobleem: een VPN-runbook

De client zegt verbinding geweigerd direct nadat je de CRL opnieuw hebt gegenereerd, dus de CRL lijkt schuldig. Dat is hij niet. Weigering is een antwoord van de transportlaag, en certificaatvalidatie gebeurt later, in de handshake van de tunnel. De timing is context, geen bewijs.

Twee controles scheiden de gevallen in minder dan een minuut, en geen van beide raakt de vertrouwensinstellingen aan.

Lees de fout op de laag die hem produceerde

ECONNREFUSED van connect betekent dat de transportpoging is geweigerd: iets antwoordde met een reset, of de stack meldde een onbereikbare poort. Een certificaatprobleem kan die fout niet veroorzaken, omdat de TLS-handshake nooit begint zonder transportverbinding. Zie je een weigering, dan kwam de client nooit ver genoeg om een certificaat te presenteren. Dat ene feit sluit intrekking als oorzaak uit.

Het omgekeerde geldt ook. Een ingetrokken certificaat levert een voltooide TCP-verbinding en een mislukte handshake, die op de server als verificatiefout wordt gelogd.

TCP-weigering: niemand luistert

Controleer voor TCP of de bedoelde instantie draait en gebonden is aan het adres en de poort in het profiel. ss -lntp toont luisteraars, en het ontbreken daarvan is de gebruikelijke verklaring. Een firewall die weigert in plaats van te droppen levert hetzelfde bericht aan de clientkant, daarom controleer je beide.

Controleer ook de adresfamilie. Een dienst die aan 127.0.0.1 of alleen aan IPv6 is gebonden, weigert een client die naar de andere resolvet.

Lees daarna het servicelog in plaats van te gissen. Een herstart na CA-onderhoud kan mislukken op een onleesbaar of ontbrekend bestand en nooit de luisterstatus bereiken, en het log noemt het bestand. Dat is een opstartfout, een andere bug dan een geweigerd certificaat.

UDP heeft geen handshake om te weigeren

OpenVPN over UDP brengt geen verbinding tot stand in TCP-zin, dus bij connect valt er niets te weigeren. Op Linux kan een fout die een UDP-socket toont, komen van een ICMP port-unreachable die door een eerder datagram is gegenereerd. De manpage udp(7) beschrijft dat asynchrone gedrag.

Daarom kan een UDP-client een weigering afdrukken terwijl het serverproces draait maar niet aan het verwachte adres is gebonden.

Waar een CRL echt wordt gecontroleerd

De CRL wordt tijdens de TLS-handshake geraadpleegd, nadat de tegenpartij zijn certificaat heeft gepresenteerd, en alleen als de serverconfiguratie dat toestaat. De OpenVPN-optie crl-verify wijst naar het bestand, en een fout verschijnt in het serverlog als een verificatiefout die het certificaat noemt.

Een ingetrokken client verbindt dus op de transportlaag en faalt daarna bij de authenticatie. Dezelfde server, dezelfde poort, volledig ander bericht.

Controleer de uitgever en de geldigheidsdatums van de CRL wanneer je dat stadium bereikt. Een CRL die door de verkeerde CA is ondertekend, of een die verliep voordat de client verbond, levert verificatiefouten op die niets met het certificaat van de client zelf te maken hebben.

Een kort runbook voor de volgende keer

Bevestig eerst het transport: luisteraar aanwezig, juiste adresfamilie, firewall die niet weigert. Bevestig daarna dat de dienst zijn luisterstatus bereikte door het opstartlog te lezen. En pas dan kijk je naar handshake-fouten op zoek naar verificatieberichten. Houd die volgorde vast, want elke stap sluit een hele klasse oorzaken uit.

Noteer het transport, de opgeloste bestemming, de poort en de exacte fouttekst. Een herinstallatie van de client vernietigt dat bewijs en verandert meestal niets.