OpenVPN: l'establiment de TLS ha fallat, en quina branca ets?

La línia que diu que l'establiment de TLS ha fallat és el final d'una història, no l'inici. L'important és l'esdeveniment immediatament anterior, perquè aquest esdeveniment anomena quina de quatre falles molt diferents tens. Un temps d'espera, un desajust del canal de control, un certificat rebutjat i una falla després de la negociació produeixen el mateix titular. Tria la branca a partir de les proves i la correcció deixa de ser una endevinalla.

Llegeix l'últim esdeveniment abans de la falla

Desplaça't cap amunt en lloc de llegir l'última línia. L'esdeveniment previ a la desconnexió normalment anomena l'etapa: cap resposta, un error mentre s'intercanvien paquets de control, un resultat de verificació o una negociació correcta seguida d'un resultat d'autenticació. Cadascun pertany a un propietari diferent. Aquesta única línia decideix quina secció de les de sota s'aplica.

Desa el text de l'error amb la versió del client, el punt final i el transport. Mantén les claus, les contrasenyes i els perfils sense censurar fora de tot el que publiquis.

Un primer error precís val més que un llarg fragment de registre. Anomena l'etapa, i l'etapa anomena el propietari.

Branca primera: no va tornar res

Si el client ha enviat el seu primer paquet i no ha rebut res d'utilitat, el problema és al camí o a l'obertura. Confirma que el perfil coincideix amb una opció que l'operador ofereix de debò: adreça, port i UDP o TCP. Després comprova si el punt final és accessible des d'aquesta xarxa. Anota quina de les dues comprovacions ha fallat abans de continuar.

Un navegador que carrega una pàgina al mateix nom d'amfitrió només demostra que un servei web ha respost. Fins i tot una connexió TCP acceptada no diu res sobre si OpenVPN ha acabat la negociació.

Si el perfil funciona en una altra xarxa de confiança, conserva aquesta comparació. Localitza la restricció en un camí o un intermediari.

Branca segona: el canal de control no coincideix

Quan l'intercanvi comença i després s'atura, la configuració del canal de control és el primer sospitós. tls-auth i tls-crypt han de coincidir amb el desplegament, i el material d'un altre servidor no produirà un intercanvi útil. Aquesta falla passa abans de qualsevol inici de sessió. Un perfil copiat d'un servidor més antic és la font habitual.

Restablir la contrasenya no substitueix aquesta configuració, i manllevar una clau d'un altre servei no és una correcció de compatibilitat. Obtén el perfil pel canal verificat de l'operador i anota la versió de client que espera.

Registra l'error de negociació concret en lloc d'activar un munt d'algorismes antics per veure què aguanta. Un text d'error capturat és el que permet a l'operador comprovar el seu costat.

Branca tercera: s'ha rebutjat un certificat

Una falla explícita de verificació anomena el certificat que no li agrada. Comprova primer el rellotge del dispositiu i després llegeix quin objecte ha fallat: el certificat del servidor, el del client o un emissor de la cadena. La caducitat, un emissor no fiable i una identitat inesperada són tres missatges diferents.

Mantén la verificació activada mentre obtens material corregit. Acceptar un certificat no relacionat elimina l'error sense demostrar que has arribat al servidor previst.

Anota si la falla segueix la xarxa o el perfil. Un error de certificat que apareix pertot arreu no és un problema de camí.

Branca quarta: la negociació s'ha acabat i una altra cosa ha fallat

Quan l'intercanvi d'identitat reeixeix, la falla restant pertany a l'autenticació o a l'encaminament. Un rebuig explícit del compte és una qüestió d'autenticació, i un túnel connectat amb llocs inabastables és una qüestió d'encaminament o DNS. Continuar substituint opcions de TLS en aquest moment danya una etapa que ja funcionava.

Quan informis del problema, digues si fallen totes les xarxes, si un altre perfil funciona i si el servidor ha registrat l'intent. El silenci del servidor i un rebuig seu se situen en límits diferents.