Un error, tres secretos: ¿qué credencial de VPN ha fallado?
El cliente muestra un error para cada etapa. Lea la asociación, el intercambio de usuario y el método antes de restablecer una contraseña que nadie comprobó.
«La autenticación ha fallado» puede apuntar a un certificado de servidor, a una clave precompartida de la máquina o a una contraseña de usuario. A cuál se refiere depende del protocolo, porque cada protocolo define un conjunto distinto de secretos. Restablezca el equivocado y el error sobrevive sin cambios. La salida consiste en establecer cuántas pruebas exige el protocolo antes de tocar nada.
Dos pruebas que apuntan en direcciones opuestas
Un túnel debe responder si llegó a la puerta de enlace correcta y, por separado, quién es el usuario. La prueba de la puerta de enlace es de nivel de máquina: un certificado de servidor, una clave precompartida o una clave pública estática. La prueba del usuario es de nivel de persona: una contraseña, un token, un certificado de cliente o nada en absoluto. Son direcciones opuestas de confianza y consumen material distinto.
IKEv2 realiza la prueba de la puerta de enlace dentro de IKE_AUTH y, cuando se usa EAP, ejecuta después la prueba del usuario en un intercambio aparte. La especificación de IKEv2 las mantiene como secciones distintas, lo que es una pista fuerte sobre dónde mirar cuando un solo mensaje cubre ambas rondas.
Lea la etapa, no el mensaje
El cliente muestra una sola cadena de error, sea cual sea la etapa que falló, así que la cadena en sí casi no lleva información. Lo que lleva información es el estado que puede inspeccionar en cada etapa: si existe una asociación, si comenzó un intercambio de usuario y si el cliente ofreció el método que quería la puerta de enlace. La tabla ordena las etapas de esa manera y no por el nombre del protocolo.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
Solo la segunda fila trata de una credencial que un usuario puede volver a escribir. Las otras tres son hechos de configuración, y esa desproporción explica por qué tantos de estos informes acaban con un restablecimiento de contraseña que no cambia nada. Lea la fila que coincide con su evidencia antes de tocar un campo.
Un protocolo de dos secretos enseña sus cartas
L2TP sobre IPsec hace visible el recuento, porque las dos comprobaciones ocurren en procesos distintos. La capa IPsec debe levantarse primero con una clave precompartida o un certificado, y solo entonces el PPP de dentro intenta un inicio de sesión de usuario.
Cuando el secreto de la máquina es incorrecto, no se forma asociación y la credencial del usuario nunca se prueba. Cuando el secreto de la máquina es correcto y el secreto del usuario es incorrecto, la asociación existe y PPP rechaza el inicio de sesión una vez que el túnel ya está levantado. Ambos producen el mismo mensaje en pantalla a partir de dos sucesos distintos.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerUna lista de asociaciones vacía descarta la capa de usuario de inmediato, así que compruébela antes de la contraseña. Una asociación establecida con fallos de PPP repetidos apunta al otro lado, a la capa de usuario o al protocolo de autenticación que hay dentro. Ninguna de las dos conclusiones está disponible en el texto de error del cliente.
De qué depende realmente el acceso solo con contraseña
El acceso solo con contraseña es habitual en L2TP, PPTP, SSTP e IKEv2 con EAP. WireGuard no tiene esa opción en absoluto, porque sus pares son claves y no usuarios. En OpenVPN la respuesta viene del requisito de certificado de cliente del servidor: una puerta de enlace que exige certificado y contraseña a la vez seguirá rechazando a un cliente solo con contraseña, se escriba lo que se escriba en el campo.
Qué componente necesita se deduce de la misma respuesta. Un inicio de sesión con contraseña bajo IKEv2 requiere un cliente que hable EAP, mientras que un inicio de sesión con certificado necesita la clave privada del cliente y la cadena del servidor. Instale el equivocado y el fallo se lee como un error de credencial aunque lo que falte sea el propio método de autenticación.
Cambie una cosa y vuelva a probar
Establezca primero tres hechos: qué protocolo se ejecuta, cuántos secretos define y cuáles de ellos pertenecen a la máquina y no al usuario. Las máquinas fallan en la primera etapa y las personas fallan en la segunda, y confundir ambas es todo este problema.
Después cambie exactamente una cosa y vuelva a probar desde el mismo cliente. Esa disciplina convierte un fallo confuso en una corrección que puede describir a la siguiente persona, y eso es más útil que una conexión que funciona y que nadie sabe explicar.