Conexión rexeitada non é un problema de certificado: guía de VPN

O cliente di que a conexión foi rexeitada xusto despois de rexenerar a CRL, así que a CRL parece culpable. Non o é. O rexeitamento é unha resposta da capa de transporte, e a validación do certificado ocorre máis tarde, dentro do handshake do túnel. O momento é contexto, non proba.

Dúas comprobacións separan os casos en menos dun minuto, e ningunha delas toca os axustes de confianza.

Lea o erro na capa que o produciu

Un ECONNREFUSED de connect significa que o intento de transporte foi rexeitado: algo respondeu cun reset, ou a pila informou dun porto inalcanzable. Un problema de certificado non pode producir ese erro, porque o handshake TLS nunca comeza sen unha conexión de transporte. Se ve un rexeitamento, o cliente nunca chegou o suficiente para presentar un certificado. Ese único feito descarta a revogación como causa.

O contrario tamén se cumpre. Un certificado revogado produce unha conexión TCP completada e un handshake fallido, rexistrado no servidor como erro de verificación.

Rexeitamento de TCP: ninguén está escoitando

Para TCP, comprobe se a instancia prevista está en execución e ligada ao enderezo e ao porto do perfil. ss -lntp mostra os oíntes, e a súa ausencia é a explicación habitual. Unha devasa que rexeita en lugar de descartar produce a mesma mensaxe no lado do cliente, por iso comproba ambas.

Comprobe tamén a familia de enderezos. Un servizo ligado a 127.0.0.1 ou só a IPv6 rexeitará un cliente que resolve ao outro.

Despois lea o rexistro do servizo en lugar de adiviñar. Un reinicio tras o mantemento da CA pode fallar nun ficheiro ilexible ou ausente e non chegar nunca ao estado de escoita, e o rexistro nomea o ficheiro. Iso é un fallo de arrinque, un erro distinto dun certificado rexeitado.

UDP non ten handshake que rexeitar

OpenVPN sobre UDP non establece unha conexión no sentido de TCP, así que non hai nada que rexeitar no momento de connect. En Linux, un erro que mostra un socket UDP pode vir dun ICMP port-unreachable xerado por un datagrama anterior. A páxina de manual udp(7) describe ese comportamento asíncrono.

Por iso un cliente UDP pode imprimir un rexeitamento mentres o proceso do servidor se executa pero non está ligado ao enderezo esperado.

Onde se comproba realmente unha CRL

A CRL consúltase durante o handshake TLS, despois de que o par presente o seu certificado, e só se a configuración do servidor o permite. A opción crl-verify de OpenVPN apunta ao ficheiro, e un fallo aparece no rexistro do servidor como erro de verificación que nomea o certificado.

Un cliente revogado, polo tanto, conecta na capa de transporte e despois falla a autenticación. Mesmo servidor, mesmo porto, mensaxe completamente distinta.

Comprobe o emisor e as datas de validez da CRL cando chegue a esa etapa. Unha CRL asinada pola CA equivocada, ou unha que caducou antes de que o cliente se conectase, produce erros de verificación que non teñen nada que ver co certificado do propio cliente.

Unha guía breve para a próxima vez

Confirme primeiro o transporte: oínte presente, familia de enderezos correcta, devasa que non rexeita. Despois confirme que o servizo alcanzou o seu estado de escoita lendo o rexistro de arrinque. E só entón mire os erros de handshake na procura de mensaxes de verificación. Manteña esa orde fixa, porque cada paso elimina toda unha clase de causas.

Anote o transporte, o destino resolto, o porto e o texto exacto do erro. Reinstalar o cliente destrúe esa evidencia e normalmente non cambia nada.