PSK de L2TP/IPsec rechazada: recorre el diálogo y luego los archivos

Pegas la clave precompartida del mensaje del administrador en el diálogo de NetworkManager, marcas la casilla para mostrarla y coincide carácter por carácter. La conexión sigue terminando en un fallo de autenticación antes de que el túnel esté levantado. La primera vez que lo vi supuse que la clave estaba mal; no lo estaba. Otras dos cosas deciden qué lee realmente el demonio: el archivo de secretos que el complemento escribe para esa conexión y si el valor atravesó el diálogo sin cambios.

El recorrido de abajo sigue la clave del campo al archivo, y ese es el orden que te dice dónde se perdió. Hazlo en la máquina que falla, no en la que funciona, porque la diferencia entre esas dos máquinas suele ser la disposición de los archivos y no la clave.

Empieza por el diálogo, pero no te fíes del campo

Abre la pestaña IPsec de la conexión y vuelve a escribir la clave en lugar de pegarla. Una clave copiada de un mensaje de chat, un PDF o un gestor de contraseñas puede llegar con un salto de línea final que el campo no muestra, y los caracteres visibles siguen pareciendo correctos.

Haz clic en el control de mostrar contraseña y mira el final de la cadena, no el medio. Si el cursor deja una línea vacía debajo del texto, bórrala y vuelve a escribir el último carácter. Esa única corrección resuelve una parte sorprendente de estos informes y cuesta menos que leer cualquier registro.

Si la clave viene de un sistema de tickets que parte las líneas largas, pídela por un canal que no las parta. Compara las longitudes con el administrador en vez de mirar dos cadenas una al lado de otra; un carácter perdido en un punto de corte es invisible en una fuente proporcional.

Sigue la clave dentro de /etc/ipsec.d

El complemento nunca entrega la PSK al demonio de IPsec como argumento en una línea de comandos. En su lugar guarda el valor en un archivo de secretos y hace que el demonio incluya ese archivo, añadiendo una línea include a /etc/ipsec.secrets si no hay ninguna. Lo que guarda el diálogo es una entrada para ese archivo generado, no el valor en uso.

Enumera lo que existe antes de cambiar nada:

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

Las versiones antiguas del complemento escribían un archivo por conexión, con el nombre del UUID de la conexión, por ejemplo /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Borrar un perfil en la aplicación no borra ese archivo de forma fiable. Si un archivo viejo de un servidor anterior sigue en el disco y todavía se incluye, el demonio puede elegir un secreto que pertenece a un perfil que ya no usas, y la conexión falla mientras el campo visible es correcto.

Entiende qué hizo el cambio 1.2.12 con las actualizaciones

La versión 1.2.12 del complemento sustituyó los archivos de secretos por conexión por un único archivo compartido, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Una actualización no limpia los archivos antiguos por UUID, y una línea include /etc/ipsec.d/*.secrets existente los sigue incluyendo. La versión 1.2.16 cambió el tratamiento de las propuestas predeterminadas, no la disposición de los secretos.

Esa historia explica por qué dos máquinas con lo que parece el mismo perfil se comportan distinto. La clave es idéntica; el conjunto de archivos que el demonio incluye no lo es. Cuando retires un archivo huérfano, muévelo a un lado en lugar de borrarlo, confirma la conexión y bórralo cuando el estado funcional esté registrado. Renombrarlo mantiene el valor antiguo recuperable si resulta que el fallo está en otro sitio.

Separa los caracteres que el formato de almacenamiento no puede contener

La documentación de strongSwan para la cadena de secreto compartido indica que el valor no puede contener un salto de línea ni un carácter de comilla doble. Una clave pegada desde un documento puede llevar cualquiera de los dos sin ninguna diferencia visual en un diálogo normal.

Desde 1.2.12 el valor guardado no es texto plano. El complemento codifica la PSK en base64 antes de que llegue al archivo, y las notas de la versión presentan esa codificación como la razón por la que ahora se acepta una comilla doble en una clave. Una comilla escrita en el campo es, por tanto, representable; lo mismo no vale para todos los caracteres de control.

La longitud es otra restricción. No hay un mínimo universal en el software L2TP/IPsec: algunos clientes aceptan claves más cortas de veinte caracteres y algunas puertas de enlace imponen un mínimo. Si se rechaza una clave corta, la regla pertenece a la política del servidor o a la validación de ese cliente, y subir algo en local no lo cambiará.

Lee qué capa de autenticación falló

Ejecuta primero ipsec --version, porque strongSwan y Libreswan usan nombres de archivo y sintaxis distintos, y un consejo para uno puede dañar al otro. Luego lee la etapa del fallo en el mensaje del cliente o en el registro del demonio: una queja sobre la clave precompartida es un evento distinto de un nombre de usuario y una contraseña rechazados.

La PSK autentica los extremos del túnel. El nombre de usuario y la contraseña autentican a la persona dentro de L2TP, y PPP se ocupa de ellos una vez levantada la asociación IPsec. Una PSK correcta con una cuenta equivocada sigue fallando, y cambiar la cuenta no reparará una clave que el demonio nunca leyó bien.

Cuando cierres el ticket, anota las cuatro cosas: versión del complemento, archivo de secretos en uso, si la clave se reescribió o se pegó y la capa que nombra el error. Así, quien repita este recorrido más adelante podrá saltar directo a la diferencia entre la máquina que funciona y la que falla.