Error de autenticación VPN: rara vez es el puerto o el DNS

Que la autenticación falle significa que el servicio recibió una identidad y la rechazó, una afirmación más estrecha de lo que la mayoría lee en ella. El puerto está abierto, la sesión TLS puede haberse completado y algo de las credenciales o de la cuenta fue rechazado. Cambiar la configuración de red no puede arreglarlo, y repetir el intento puede bloquear la cuenta. El texto del error ya nombra la etapa, así que empiece por ahí.

El error ya le dijo qué etapa falló

Una conexión que nunca completa su protocolo de enlace TLS no ha llegado a la autenticación en absoluto. Una conexión que completa el protocolo de enlace y luego informa un rechazo de credenciales sí ha llegado y ha fallado allí. Esos dos resultados requieren investigaciones distintas, y a menudo se confunden porque ambos terminan con una ventana cerrada.

OpenVPN hace explícita la distinción con un mensaje AUTH_FAILED del servidor, que es una decisión y no un error de transporte. Un tiempo de espera en la negociación TLS o un error de verificación del certificado pertenecen a la etapa anterior. Lea cuál de los dos tiene antes de tocar las credenciales, porque restablecer la contraseña no puede reparar un protocolo de enlace y cambiar el cortafuegos no puede reparar un inicio de sesión rechazado. Una línea del registro del cliente responde la pregunta.

La misma lógica se aplica a una sesión que conecta y luego cae. Un fallo de reautenticación en el minuto cuarenta es un defecto distinto de un rechazo en el primer inicio de sesión, y el intervalo es la pista.

Confirme que el perfil apunta al servicio correcto

La cuenta que se usa en el sitio web de un proveedor no siempre es la cuenta que acepta su puerta de enlace VPN. Un perfil guardado también puede apuntar a una puerta de enlace antigua mucho después de que el servicio se haya mudado.

Compare el punto de conexión del perfil con el que publicó el operador y compruebe qué sistema de identidad consulta la puerta de enlace. Restablecer la contraseña en el portal web no cambia nada si el túnel se autentica contra un directorio separado. Las credenciales de un servidor público no relacionado no funcionarán en el suyo, y probar una contraseña de trabajo en un perfil recibido por un mensaje no fiable es un mal intercambio en cualquier caso. Confirme el origen antes de escribir nada.

Dos minutos en el perfil evitan un día de adivinar credenciales.

El formato de inicio de sesión es parte de las credenciales

Un nombre de usuario puede necesitar una forma de correo electrónico, un prefijo de dominio o un sufijo de directorio. La puerta de enlace compara la cadena que recibió, así que la forma es parte de las credenciales y no un adorno.

Luego descarte las causas aburridas antes de escalar. Revise la distribución del teclado, cualquier espacio final introducido al copiar y una entrada antigua del gestor de contraseñas. Tras un restablecimiento, confirme que la VPN usa la misma fuente de identidad que la página donde se cambió la contraseña. Si esos detalles son correctos, deje de adivinar y pregunte al operador si la cuenta está habilitada y autorizada para el acceso VPN. Eso es una corrección del lado del servicio, no un ajuste del cliente.

openvpn --config office.ovpn --verb 3
journalctl -u openvpn-client@office -n 40 --no-pager

La línea del registro que lleva AUTH_FAILED suele incluir un código de motivo o una cadena de desafío. Cópiela exactamente en lugar de parafrasearla cuando pida ayuda.

Los segundos factores tienen su propio contrato

El perfil puede esperar un código de un solo uso, un desafío interactivo o un inicio de sesión en el navegador que devuelva un token al cliente. Use el flujo que admite el operador en lugar de inventar uno.

No añada un código a la contraseña salvo que ese formato se exija explícitamente, porque algunas implementaciones usan un campo separado y otras una cadena de desafío. Para los códigos basados en tiempo, revise el reloj del dispositivo, ya que unos minutos de desviación invalidan todos los códigos. Si el inicio de sesión en el navegador tiene éxito y el cliente nunca se reanuda, anote exactamente ese punto, porque identifica la entrega y no la credencial. Otro restablecimiento de contraseña probablemente no ayudará.

El límite de sesiones es el otro rechazo habitual. Si la cuenta permite una sola sesión, un segundo inicio de sesión puede terminar el primero, y el síntoma parece una conexión intermitente en lugar de una política.

Un certificado no es una contraseña

Un certificado de cliente puede caducar o revocarse mientras la contraseña de la cuenta sigue siendo perfectamente correcta. La frase de paso de una clave privada es de nuevo un tercer secreto, y protege un archivo y no una cuenta.

Lea el error antes de sustituir nada y luego obtenga el reemplazo correcto del operador verificado. Mantenga activada la verificación de identidad del servidor mientras lo hace: aceptar un certificado no relacionado o copiar la clave privada de otra persona no es una reparación, es un segundo incidente. Después pruebe el recurso que realmente necesita, porque un túnel conectado con un servicio inalcanzable pertenece a otra investigación. Anote qué etapa falló para que la siguiente persona no reinicie todo el proceso.

Si la sesión se establece y falla después, registre el intervalo y cualquier evento de renovación cercano. Ese registro separa un problema de vida útil del token de un fallo en el primer inicio de sesión, y es la diferencia entre una reparación de cinco minutos y una semana de reintentos.