Keyfile o Netplan: ¿dónde se guarda realmente el perfil de VPN?
Una VPN guardada puede vivir en un keyfile o en un archivo Netplan generado. Haga coincidir el UUID de la conexión con su dueño real antes de editar algo que se reescribe.
Encontrar el archivo que importó es la parte fácil y, a menudo, el comienzo equivocado. Lo importante es qué archivo lee hoy NetworkManager como la conexión guardada, y eso depende de un identificador de conexión y del backend de configuración que los paquetes instalados usan realmente. Editar la importación antes de responder esa pregunta es como una VPN que funciona se convierte en dos configuraciones medio correctas.
El archivo importado no es el perfil guardado
Tres nombres flotan alrededor de cada problema de VPN: el nombre de la conexión, el nombre del archivo que importó y la interfaz virtual que aparece cuando el túnel se levanta. Ninguno identifica la configuración guardada, y el nombre de una conexión puede editarse mientras el archivo que hay detrás conserva su identificador original.
Empiece con un inventario de solo lectura y elija la VPN deseada por identificador en lugar de por etiqueta:
nmcli -f NAME,UUID,TYPE connection show
Deje los nombres de host de los extremos y las etiquetas de identidad fuera de cualquier inventario que pegue en un ticket. La parte útil es el tipo y el identificador; el resto es contexto que un desconocido no necesita. Redacte el resto antes de compartirlo y diga que lo hizo, para que nadie se pregunte qué significan los huecos.
Las ubicaciones del keyfile no significan lo mismo
Con el complemento keyfile nativo, los archivos de conexión pueden aparecer en tres directorios, y la diferencia entre ellos es la persistencia, no la comodidad.
| Location | Role |
|---|---|
/etc/NetworkManager/system-connections/ | Administrator-owned persistence |
/usr/lib/NetworkManager/system-connections/ | Package-supplied defaults, replaced on upgrade |
/run/NetworkManager/system-connections/ | Runtime state, regenerated and not durable |
Editar la copia en tiempo de ejecución parece exitoso hasta el siguiente arranque, cuando el cambio se evapora y el archivo parece revertido misteriosamente. Editar la copia que entrega el paquete funciona hasta que una actualización la reemplaza, que es una versión más lenta y confusa de la misma lección.
La documentación del keyfile añade un detalle que conviene respetar: esos archivos pueden contener claves privadas y frases de contraseña, y NetworkManager ignora cualquier keyfile que usuarios distintos de root puedan leer o escribir. Ampliar los permisos del directorio para buscar un ajuste rompe el comportamiento de carga que intentaba inspeccionar.
Cuando Netplan es dueño de la persistencia
En Ubuntu, la integración de NetworkManager descrita en la documentación de Netplan, disponible desde 23.10, cambia dónde vive la copia duradera. Para las conexiones no temporales escribe /etc/netplan/90-NM-<connection UUID>.yaml y genera un perfil efímero de NetworkManager bajo /run/NetworkManager/system-connections/.
Eso es una integración de distribución, no una regla para toda instalación de NetworkManager. Confirme que los paquetes instalados realmente la usan antes de ir a buscar un archivo YAML. Recuerde también que un perfil en tiempo de ejecución puede ser una representación generada de otra cosa en lugar de la fuente que vale la pena editar. Dos comandos de comprobación ahorran una hora de editar el archivo equivocado.
El ejemplo documentado guarda una conexión OpenVPN mediante el tipo Netplan nm-devices con datos de paso de NetworkManager. Que Netplan no tenga una interpretación dedicada de un campo VPN concreto no significa que su VPN guardada se haya perdido; significa que el campo viaja como datos opacos.
Las interfaces transitorias no son perfiles
La activación crea conexiones e interfaces virtuales temporales que nunca debían persistir. La integración deliberadamente no escribe un archivo YAML nuevo para cada una, así que su ausencia en /etc/netplan no dice nada sobre si el perfil padre está guardado.
Si persigue un archivo que aparece y desaparece, probablemente esté mirando uno de estos y no su configuración. Compruebe si sobrevive a un reinicio antes de sacar cualquier conclusión de su contenido. Un archivo en tiempo de ejecución que desaparece al reiniciar le dice que nunca fue la fuente, y esa única observación redirige toda la investigación. También explica por qué una edición pareció exitosa en su momento.
Secretos y propiedad
Un perfil puede referenciar un certificado o una clave guardados en otro lugar por completo, y una contraseña puede pertenecer a NetworkManager, ser suministrada por un agente secreto de la sesión de usuario, o no guardarse deliberadamente. Por lo tanto, localizar un solo archivo resuelve muy poco sobre lo que exigirá un arranque sin supervisión.
Inspeccione las referencias y los indicadores de secretos sin imprimir valores secretos. Un inicio de sesión de escritorio puede hacer disponible un agente que faltaba durante el arranque, y copiar un archivo en tiempo de ejecución generado no reproduce ese agente. El síntoma práctico es un túnel que conecta cuando una persona inicia sesión y falla cuando la máquina arranca sola. Ese patrón apunta a la propiedad de los secretos, no al enrutamiento.
Haga los cambios aprobados a través del gestor que posee la conexión y luego verifique tanto el identificador guardado como la conexión efectiva. Mantenga un único propietario persistente, porque editar la importación, un keyfile generado y una fuente YAML por separado deja tres explicaciones competidoras de lo que usará la próxima reconexión. Elija la que realmente persiste, edite solo esa y anote en el ticket qué archivo trató como autoritativo. La siguiente persona le agradecerá una línea de procedencia.