Un error, tres secrets: quina credencial de VPN ha fallat?
El client mostra un error per a cada etapa. Llegeix l’associació, l’intercanvi d’usuari i el mètode abans de restablir una contrasenya que ningú no ha comprovat.
«L’autenticació ha fallat» pot apuntar a un certificat de servidor, a una clau prèvia compartida de la màquina o a una contrasenya d’usuari. A quin es refereix depèn del protocol, perquè cada protocol defineix un conjunt de secrets diferent. Restabliu el que no toca i l’error sobreviu sense canvis. La sortida és establir quantes proves exigeix el protocol abans de tocar res.
Dues proves que apunten en direccions oposades
Un túnel ha de respondre si ha arribat a la passarel·la correcta i, per separat, qui és l’usuari. La prova de la passarel·la és a nivell de màquina: un certificat de servidor, una clau prèvia compartida o una clau pública estàtica. La prova de l’usuari és a nivell de persona: una contrasenya, un testimoni, un certificat de client o res de res. Són direccions oposades de confiança i consumeixen material diferent.
IKEv2 fa la prova de la passarel·la dins d’IKE_AUTH i, quan s’usa EAP, executa després la prova de l’usuari en un intercanvi a part. L’especificació d’IKEv2 les manté com a seccions diferents, cosa que és una pista forta sobre on mirar quan un sol missatge cobreix les dues rondes.
Llegeix l’etapa, no el missatge
El client mostra una sola cadena d’error sigui quina sigui l’etapa que ha fallat, així que la cadena en si gairebé no porta informació. El que porta informació és l’estat que podeu inspeccionar a cada etapa: si existeix una associació, si ha començat un intercanvi d’usuari i si el client ha ofert el mètode que volia la passarel·la. La taula ordena les etapes així en lloc de pel nom del protocol.
| 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 |
Només la segona fila tracta d’una credencial que un usuari pot tornar a escriure. Les altres tres són fets de configuració, i aquest desajust és la raó per la qual tants d’aquests informes acaben amb un restabliment de contrasenya que no canvia res. Llegiu la fila que coincideix amb la vostra evidència abans de tocar cap camp.
Un protocol de dos secrets ensenya les cartes
L2TP sobre IPsec fa visible el recompte, perquè les dues comprovacions passen en processos diferents. La capa IPsec ha d’aixecar-se primer amb una clau prèvia compartida o un certificat, i només llavors el PPP que hi ha a dins intenta un inici de sessió d’usuari.
Quan el secret de la màquina és incorrecte, no es forma cap associació i la credencial d’usuari no s’intenta mai. Quan el secret de la màquina és correcte i el secret de l’usuari és incorrecte, l’associació existeix i el PPP rebutja l’inici de sessió quan el túnel ja està aixecat. Els dos casos produeixen el mateix missatge a la pantalla a partir de dos esdeveniments diferents.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerUna llista d’associacions buida elimina la capa d’usuari de seguida, així que comproveu-la abans de la contrasenya. Una associació establerta amb fallades de PPP repetides apunta a l’altra banda, a la capa d’usuari o al protocol d’autenticació que hi ha a dins. Cap de les dues conclusions no es pot treure del text d’error del client.
De què depèn realment l’accés només amb contrasenya
L’accés només amb contrasenya és habitual per a L2TP, PPTP, SSTP i IKEv2 amb EAP. WireGuard no té cap opció així, perquè els seus parells són claus i no usuaris. Per a OpenVPN la resposta ve del requisit de certificat de client del servidor: una passarel·la que exigeix certificat i contrasenya alhora continuarà rebutjant un client només amb contrasenya, escrigui el que escrigui al camp.
Quin component necessiteu es desprèn de la mateixa resposta. Un inici de sessió amb contrasenya sota IKEv2 requereix un client que parli EAP, mentre que un inici de sessió amb certificat necessita la clau privada del client i la cadena del servidor. Instal·leu el que no toca i la fallada es llegeix com un error de credencial encara que el que falta sigui el mètode d’autenticació mateix.
Canvieu una cosa i torneu a provar
Establiu primer tres fets: quin protocol s’executa, quants secrets defineix i quins d’ells pertanyen a la màquina i no a l’usuari. Les màquines fallen a la primera etapa i les persones fallen a la segona, i confondre les dues és tot aquest problema.
Després canvieu exactament una cosa i torneu a provar des del mateix client. Aquesta disciplina converteix una fallada confusa en una correcció que podeu descriure a la propera persona, cosa més útil que una connexió que funciona i que ningú no sap explicar.