Un erro, tres segredos: que credencial de VPN fallou?
O cliente mostra un erro para cada etapa. Lea a asociación, o intercambio de usuario e o método antes de restablecer un contrasinal que ninguén comprobou.
«A autenticación fallou» pode apuntar a un certificado de servidor, a unha clave precompartida da máquina ou a un contrasinal de usuario. A cal se refire depende do protocolo, porque cada protocolo define un conxunto distinto de segredos. Restableza o equivocado e o erro sobrevive sen cambios. A saída consiste en establecer cantas probas esixe o protocolo antes de tocar nada.
Dúas probas que apuntan en direccións opostas
Un túnel debe responder se chegou á pasarela correcta e, por separado, quen é o usuario. A proba da pasarela é de nivel de máquina: un certificado de servidor, unha clave precompartida ou unha clave pública estática. A proba do usuario é de nivel de persoa: un contrasinal, un token, un certificado de cliente ou nada de nada. Son direccións opostas de confianza e consomen material distinto.
IKEv2 realiza a proba da pasarela dentro de IKE_AUTH e, cando se usa EAP, executa despois a proba do usuario nun intercambio aparte. A especificación de IKEv2 manténas como seccións distintas, o que é unha pista forte sobre onde mirar cando unha soa mensaxe cobre ambas as quendas.
Lea a etapa, non a mensaxe
O cliente mostra unha soa cadea de erro, sexa cal sexa a etapa que fallou, así que a cadea en si case non leva información. O que leva información é o estado que pode inspeccionar en cada etapa: se existe unha asociación, se comezou un intercambio de usuario e se o cliente ofreceu o método que quería a pasarela. A táboa ordena as etapas dese xeito e non polo nome do 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 |
Só a segunda fila trata dunha credencial que un usuario pode volver escribir. As outras tres son feitos de configuración, e esa desconexión explica por que tantos destes informes acaban cun restablecemento de contrasinal que non cambia nada. Lea a fila que coincide coa súa evidencia antes de tocar un campo.
Un protocolo de dous segredos amosa as súas cartas
L2TP sobre IPsec fai visible a conta, porque as dúas comprobacións ocorren en procesos distintos. A capa IPsec debe levantarse primeiro cunha clave precompartida ou un certificado, e só entón o PPP de dentro tenta un inicio de sesión de usuario.
Cando o segredo da máquina é incorrecto, non se forma asociación e a credencial do usuario nunca se proba. Cando o segredo da máquina é correcto e o segredo do usuario é incorrecto, a asociación existe e PPP rexeita o inicio de sesión unha vez que o túnel xa está levantado. Ambos producen a mesma mensaxe na pantalla a partir de dous sucesos distintos.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerUnha lista de asociacións baleira descarta a capa de usuario de inmediato, así que compróbea antes do contrasinal. Unha asociación establecida con fallos de PPP repetidos apunta ao outro lado, á capa de usuario ou ao protocolo de autenticación que hai dentro. Ningunha das dúas conclusións está dispoñible no texto de erro do cliente.
De que depende realmente o acceso só con contrasinal
O acceso só con contrasinal é habitual en L2TP, PPTP, SSTP e IKEv2 con EAP. WireGuard non ten esa opción en absoluto, porque os seus pares son claves e non usuarios. En OpenVPN a resposta vén do requisito de certificado de cliente do servidor: unha pasarela que esixe certificado e contrasinal á vez seguirá rexeitando un cliente só con contrasinal, escríbase o que se escriba no campo.
Que compoñente necesita dedúcese da mesma resposta. Un inicio de sesión con contrasinal baixo IKEv2 require un cliente que fale EAP, mentres que un inicio de sesión con certificado necesita a clave privada do cliente e a cadea do servidor. Instale o equivocado e o fallo lese como un erro de credencial aínda que o que falta sexa o propio método de autenticación.
Cambie unha cousa e volva probar
Estableza primeiro tres feitos: que protocolo se executa, cantos segredos define e cales deles pertencen á máquina e non ao usuario. As máquinas fallan na primeira etapa e as persoas fallan na segunda, e confundir ambas é todo este problema.
Despois cambie exactamente unha cousa e volva probar desde o mesmo cliente. Esa disciplina converte un fallo confuso nunha corrección que pode describir á seguinte persoa, e iso é máis útil que unha conexión que funciona e que ninguén sabe explicar.