Connexió rebutjada no és un problema de certificat: guia de VPN

El client diu que la connexió ha estat rebutjada just després de regenerar la CRL, així que la CRL sembla culpable. No ho és. El rebuig és una resposta de la capa de transport, i la validació del certificat passa més tard, dins de l’apretada de mans del túnel. El moment és context, no prova.

Dues comprovacions separen els casos en menys d’un minut, i cap de les dues no toca la configuració de confiança.

Llegeix l’error a la capa que l’ha produït

Un ECONNREFUSED provinent de connect vol dir que l’intent de transport ha estat rebutjat: alguna cosa ha respost amb un reset, o la pila ha informat d’un port inabastable. Un problema de certificat no pot produir aquest error, perquè l’apretada de mans TLS no comença mai sense una connexió de transport. Si veus un rebuig, el client no ha arribat mai prou lluny per presentar un certificat. Aquest sol fet descarta la revocació com a causa.

També es compleix el contrari. Un certificat revocat produeix una connexió TCP completada i una apretada de mans fallida, registrada al servidor com un error de verificació.

Rebuig de TCP: ningú no escolta

Per a TCP, comprova si la instància prevista s’executa i està lligada a l’adreça i al port del perfil. ss -lntp mostra els oients, i la seva absència és l’explicació habitual. Un tallafoc que rebutja en lloc de descartar produeix el mateix missatge al costat del client, i per això comproves les dues coses.

Comprova també la família d’adreces. Un servei lligat a 127.0.0.1 o només a IPv6 rebutjarà un client que es resol a l’altra.

Després llegeix el registre del servei en lloc d’endevinar. Un reinici després del manteniment de la CA pot fallar en un fitxer il·legible o absent i no arribar mai a l’estat d’escolta, i el registre anomena el fitxer. Això és una fallada d’arrencada, un error diferent d’un certificat rebutjat.

L’UDP no té cap apretada de mans per rebutjar

OpenVPN sobre UDP no estableix una connexió en el sentit de TCP, així que no hi ha res a rebutjar en el moment de connect. A Linux, un error que apareix en un sòcol UDP pot venir d’un ICMP port-unreachable generat per un datagrama anterior. La pàgina de manual udp(7) descriu aquest comportament asíncron.

Per això un client UDP pot imprimir un rebuig mentre el procés del servidor s’executa però no està lligat a l’adreça esperada.

On es comprova realment una CRL

La CRL es consulta durant l’apretada de mans TLS, després que el peer presenti el seu certificat, i només si la configuració del servidor ho permet. L’opció crl-verify de l’OpenVPN apunta al fitxer, i una fallada apareix al registre del servidor com un error de verificació que anomena el certificat.

Un client revocat, doncs, connecta a la capa de transport i després falla l’autenticació. Mateix servidor, mateix port, missatge completament diferent.

Comprova l’emissor i les dates de validesa de la CRL quan arribis a aquesta fase. Una CRL signada per la CA equivocada, o una que va caducar abans que el client es connectés, produeix errors de verificació que no tenen res a veure amb el certificat del propi client.

Una guia breu per a la propera vegada

Confirma primer el transport: oient present, família d’adreces correcta, tallafoc que no rebutja. Després confirma que el servei ha arribat a l’estat d’escolta llegint el registre d’arrencada. I només llavors mira els errors d’apretada de mans buscant missatges de verificació. Mantén aquest ordre fix, perquè cada pas elimina tota una classe de causes.

Anota el transport, la destinació resolta, el port i el text exacte de l’error. Reinstal·lar el client destrueix aquesta evidència i normalment no canvia res.