nmcli sigue pidiendo la contraseña de la VPN: guarda el secreto localmente

El mismo perfil, dos sesiones: se conecta desde el escritorio y se cuelga por SSH en una solicitud que nada puede responder. Nada está roto y no se ha perdido ningún ajuste. NetworkManager pide la credencial a un agente de secretos, y un agente de secretos es un componente de escritorio que no existe en la sesión que estás usando.

Ejecuta la secuencia de abajo y el túnel se levantará sin interfaz gráfica, con la advertencia de que guardar un secreto cambia quién puede usar ese perfil.

Confirma el diagnóstico antes de tocar nada

La diferencia entre la activación interactiva y la no interactiva es todo el diagnóstico. Si nmcli --ask connection up tiene éxito mientras una activación normal se atasca, el perfil es correcto y falta el origen del secreto. Esa única comparación te ahorra reescribir una configuración que funciona.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office IPsec" | grep -i flags

Lee las opciones en lugar de adivinarlas. Los valores que significan "pregunta a un agente" son lo que buscas, y los nombres exactos de las claves varían entre complementos de VPN porque viven en el diccionario de datos propio del complemento. Un perfil FortiSSL y un perfil IPsec no usan necesariamente los mismos nombres, así que parte de la salida de tu propio perfil.

Comprueba también que el paquete del complemento para ese protocolo esté instalado. Un complemento ausente aparece como un tipo de conexión desconocido o como un error de activación que no dice nada sobre contraseñas, y perseguir el secreto en ese estado desperdicia la misma hora dos veces. Una consulta de paquetes es más barata que una tarde entera editando archivos de claves.

Mueve el secreto al archivo de claves

El archivo de conexión vive en /etc/NetworkManager/system-connections/. Los secretos no se guardan ahí por defecto, y ese es el sentido de las opciones que acabas de leer. Cambiar una opción a cero le dice a NetworkManager que el valor se guarda con el perfil en lugar de pedirse en el momento de la activación.

[vpn]
password-flags=0

[vpn-secrets]
password=YOUR-VPN-PASSWORD

Para un perfil con dos secretos, el patrón se repite: una opción por secreto en la sección [vpn], y los valores en [vpn-secrets]. Un perfil IPsec suele llevar una clave precompartida junto a la credencial de usuario, y el complemento los nombra de forma distinta a un campo de contraseña normal, así que copia los nombres de las claves de la salida de vpn.data en lugar de un artículo de blog que usara otro complemento. Un solo nombre de clave equivocado produce un perfil que carga y luego falla en la autenticación, lo que se lee exactamente como una contraseña incorrecta. Compara tu archivo con un perfil que funcione del mismo complemento antes de volver a conectarte.

Pon entre comillas los valores que contengan espacios, comillas o un signo de dólar. Un valor sin comillas con un $ dentro se leerá literalmente o se expandirá según dónde se analice, y el fallo de autenticación resultante parece una contraseña incorrecta.

Luego corrige la propiedad y el modo del archivo. Estos archivos de claves los lee un servicio privilegiado, y un archivo que otros usuarios pueden leer se trata como poco fiable, que es la razón habitual por la que un perfil editado parece ignorarse. Propietario root, modo 600, sin excepciones.

Recarga y luego activa

El archivo se lee cuando se carga la conexión, así que editarlo no basta. Recarga los perfiles y luego levanta la conexión explícitamente.

sudo nmcli connection reload
sudo nmcli connection up "Office IPsec"

Si la recarga no recoge el cambio, un reinicio completo del servicio sí lo hace, y hay informes de exactamente eso. Prefiere la recarga cuando otros enlaces importan, porque reiniciar el servicio corta todas las conexiones gestionadas, y en un host remoto eso puede terminar tu sesión antes de que el túnel que querías esté levantado.

Usa el UUID cuando los nombres sean ambiguos. Las máquinas con varios perfiles de clientes acumulan casi duplicados, y activar el equivocado produce un fallo que parece un problema de credenciales.

Cuando el secreto guardado no es el problema

Un perfil FortiSSL puede fallar incluso con una credencial guardada correcta porque el cliente nunca confía en el certificado de la puerta de enlace. Ese ajuste no está en el diálogo principal; está detrás de las opciones avanzadas de la VPN, donde se introduce el resumen del certificado de confianza. Si el registro menciona el certificado en lugar de la contraseña, estás en esta rama y ninguna cantidad de edición de [vpn-secrets] ayudará.

Aquí corresponden dos comprobaciones más. Confirma que el perfil no se importó desde un archivo que todavía apunta a una ruta que el complemento no puede leer, y confirma que el perfil es el activo y no un duplicado obsoleto. Ambos producen fallos de activación que se leen como errores de autenticación.

Decide si guardar es aceptable

Una PSK y una contraseña guardadas son legibles por cualquier cosa que se ejecute como root en esa máquina. En una máquina que controlas, es un intercambio razonable para un servicio sin interfaz. En un host compartido merece una conversación, porque el perfil ahora contiene una credencial que antes protegía el llavero del escritorio. Pregunta quién más puede llegar a root en ese host antes de decidir, no después de que el cambio esté hecho.

Si la política prohíbe guardar secretos de VPN, no debilites el perfil para hacer que funcione una tarea de cron. Ejecuta la conexión desde una sesión que tenga un agente, o usa otro mecanismo para la automatización.

Por último, anota qué perfiles llevan secretos para que nadie copie uno a un portátil sin darse cuenta. Un comentario encima de la sección de secretos con la fecha y el motivo basta, y ahorrará a alguien una revisión incómoda más adelante.