OpenVPN: fallou o establecemento de TLS, en que rama estás?

A liña que di que o establecemento de TLS fallou é o final dunha historia, non o seu principio. O importante é o acontecemento inmediatamente anterior, porque ese acontecemento nomea cal de catro fallos moi distintos tes. Un tempo de espera, un desaxuste da canle de control, un certificado rexeitado e un fallo despois da negociación producen o mesmo titular. Escolle a rama a partir das probas e a corrección deixa de ser unha conxectura.

Le o último acontecemento antes do fallo

Desprázate cara arriba en lugar de ler a última liña. O acontecemento anterior á desconexión adoita nomear a etapa: ningunha resposta, un erro ao intercambiar paquetes de control, un resultado de verificación ou unha negociación correcta seguida dun resultado de autenticación. Cada un pertence a un responsable distinto. Esa única liña decide que sección das de abaixo se aplica.

Garda o texto do erro coa versión do cliente, o punto final e o transporte. Mantén as claves, os contrasinais e os perfís sen censurar fóra de todo o que publiques.

Un primeiro erro preciso vale máis ca un longo fragmento de rexistro. Nomea a etapa, e a etapa nomea o responsable.

Rama un: non volveu nada

Se o cliente enviou o seu primeiro paquete e non recibiu nada utilizábel, o problema está na ruta ou no receptor. Confirma que o perfil coincide cunha opción que o operador ofrece de verdade: enderezo, porto e UDP ou TCP. Logo comproba se o punto final é accesíbel desde esta rede. Anota cal das dúas comprobacións fallou antes de seguir.

Un navegador que carga unha páxina no mesmo nome de host só demostra que un servizo web respondeu. Mesmo unha conexión TCP aceptada non di nada sobre se OpenVPN rematou a negociación.

Se o perfil funciona noutra rede de confianza, conserva esa comparación. Localiza a restrición nunha ruta ou nun intermediario.

Rama dous: a canle de control non coincide

Cando o intercambio comeza e logo se detén, a configuración da canle de control é o primeiro sospeitoso. tls-auth e tls-crypt deben coincidir co despregamento, e o material doutro servidor non producirá un intercambio útil. Este fallo ocorre antes de calquera inicio de sesión. Un perfil copiado dun servidor máis antigo é a fonte habitual.

Restablecer o contrasinal non substitúe esa configuración, e tomar prestada unha clave doutro servizo non é unha corrección de compatibilidade. Obtén o perfil pola canle verificada do operador e anota a versión de cliente que espera.

Rexistra o erro de negociación concreto en lugar de activar un montón de algoritmos antigos para ver que aguanta. Un texto de erro capturado é o que permite ao operador comprobar o seu lado.

Rama tres: rexeitouse un certificado

Un fallo explícito de verificación nomea o certificado que non lle gusta. Comproba primeiro o reloxo do dispositivo e logo le que obxecto fallou: o certificado do servidor, o do cliente ou un emisor da cadea. A caducidade, un emisor non fiable e unha identidade inesperada son tres mensaxes distintas.

Mantén a verificación activada mentres obtés material corrixido. Aceptar un certificado non relacionado elimina o erro sen demostrar que chegaches ao servidor previsto.

Anota se o fallo segue a rede ou o perfil. Un erro de certificado que aparece por todas partes non é un problema de ruta.

Rama catro: a negociación rematou e fallou outra cousa

Cando o intercambio de identidade ten éxito, o fallo restante pertence á autenticación ou ao encamiñamento. Un rexeitamento explícito da conta é unha cuestión de autenticación, e un túnel conectado con sitios inalcanzábeis é unha cuestión de encamiñamento ou DNS. Seguir substituíndo opcións de TLS nese momento dana unha etapa que xa funcionaba.

Cando informes do problema, di se fallan todas as redes, se funciona outro perfil e se o servidor rexistrou o intento. O silencio do servidor e un rexeitamento seu sitúanse en límites distintos.