PSK de L2TP/IPsec rebutjada: recorre el diàleg i després els fitxers

Enganxes la clau prèviament compartida del missatge de l'administrador al diàleg del NetworkManager, marques la casella per mostrar-la i coincideix caràcter per caràcter. La connexió encara acaba en un error d'autenticació abans que el túnel estigui aixecat. Quan ho vaig veure per primera vegada, vaig suposar que la clau era incorrecta; no ho era. Dues altres coses decideixen què llegeix realment el dimoni: el fitxer de secrets que l'extensió escriu per a aquesta connexió i si el valor va travessar el diàleg sense canvis.

El recorregut de sota segueix la clau del camp al fitxer, i aquest és l'ordre que et diu on s'ha perdut. Fes-ho a la màquina que falla, no a la que funciona, perquè la diferència entre aquestes dues màquines sol ser la disposició dels fitxers i no la clau.

Comença pel diàleg, però no confiïs en el camp

Obre la pestanya IPsec de la connexió i torna a escriure la clau en lloc d'enganxar-la. Una clau copiada d'un missatge de xat, d'un PDF o d'un gestor de contrasenyes pot arribar amb un salt de línia final que el camp no mostra, i els caràcters visibles continuen semblant correctes.

Fes clic al control de mostrar contrasenya i mira el final de la cadena, no el mig. Si el cursor deixa una línia buida sota el text, esborra-la i torna a escriure l'últim caràcter. Aquesta única correcció resol una part sorprenent d'aquests informes i costa menys que llegir qualsevol registre.

Si la clau ve d'un sistema de tiquets que parteix les línies llargues, demana-la per un canal que no parteixi. Compara les longituds amb l'administrador en lloc de mirar dues cadenes costat a costat; un caràcter perdut en un punt de tall és invisible en una font proporcional.

Segueix la clau dins de /etc/ipsec.d

L'extensió no passa mai la PSK al dimoni d'IPsec com a argument en una línia d'ordres. En lloc d'això desa el valor en un fitxer de secrets i fa que el dimoni inclogui aquest fitxer, afegint una línia include a /etc/ipsec.secrets si no n'hi ha cap. El que guarda el diàleg és una entrada per a aquest fitxer generat, no el valor en ús.

Llista què existeix abans de canviar res:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Les versions antigues de l'extensió escrivien un fitxer per connexió, amb el nom de l'UUID de la connexió, per exemple /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Esborrar un perfil a l'aplicació no esborra aquest fitxer de manera fiable. Si un fitxer antic d'un servidor anterior encara és al disc i encara s'inclou, el dimoni pot triar un secret que pertany a un perfil que ja no uses, i la connexió falla mentre el camp visible és correcte.

Entén què va fer el canvi 1.2.12 a les actualitzacions

La versió 1.2.12 de l'extensió va substituir els fitxers de secrets per connexió per un únic fitxer compartit, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Una actualització no neteja els fitxers antics per UUID, i una línia include /etc/ipsec.d/*.secrets existent encara els inclou. La versió 1.2.16 va canviar el tractament de les propostes per defecte, no la disposició dels secrets.

Aquesta història explica per què dues màquines amb el que sembla el mateix perfil es comporten diferent. La clau és idèntica; el conjunt de fitxers que el dimoni inclou no ho és. Quan retiris un fitxer orfe, mou-lo a un costat en lloc d'esborrar-lo, confirma la connexió i esborra'l quan l'estat funcional estigui registrat. Reanomenar-lo manté el valor antic recuperable si resulta que la fallada és en un altre lloc.

Separa els caràcters que el format d'emmagatzematge no pot contenir

La documentació de strongSwan per a la cadena de secret compartit afirma que el valor no pot contenir un salt de línia ni un caràcter de cometes dobles. Una clau enganxada d'un document pot portar qualsevol dels dos sense cap diferència visual en un diàleg normal.

Des de 1.2.12 el valor desat no és text pla. L'extensió codifica la PSK en base64 abans que arribi al fitxer, i les notes de la versió presenten aquesta codificació com la raó per la qual ara s'accepta una cometa doble en una clau. Una cometa escrita al camp és, per tant, representable; el mateix no val per a tots els caràcters de control.

La longitud és una restricció diferent. No hi ha cap mínim universal al programari L2TP/IPsec: alguns clients accepten claus més curtes de vint caràcters i algunes passarel·les imposen un mínim. Si es rebutja una clau curta, la regla pertany a la política del servidor o a la validació d'aquell client, i pujar alguna cosa en local no ho canviarà.

Llegeix quina capa d'autenticació ha fallat

Executa primer ipsec --version, perquè strongSwan i Libreswan fan servir noms de fitxer i sintaxi diferents, i un consell per a un pot fer mal a l'altre. Després llegeix l'etapa de la fallada al missatge del client o al registre del dimoni: una queixa sobre la clau prèviament compartida és un esdeveniment diferent d'un nom d'usuari i una contrasenya rebutjats.

La PSK autentica els extrems del túnel. El nom d'usuari i la contrasenya autentiquen la persona dins de L2TP, i PPP se n'encarrega després que l'associació IPsec estigui aixecada. Una PSK correcta amb un compte equivocat encara falla, i canviar el compte no repararà una clau que el dimoni mai no va llegir bé.

Quan tanquis el tiquet, anota les quatre coses: versió de l'extensió, fitxer de secrets en ús, si la clau es va reescriure o enganxar i la capa que apareix a l'error. Així, qui repeteixi aquest recorregut més endavant podrà saltar directament a la diferència entre la màquina que funciona i la que falla.