La importación en NetworkManager falla con archivos OpenVPN y WireGuard

Elegí Importar desde archivo… en Configuración de GNOME, escogí un perfil que funciona con el cliente del proveedor, y el diálogo se cerró sin añadir nada a la lista. En un segundo portátil la importación se completó, la conexión apareció con el nombre del perfil y luego falló en la primera petición de autenticación. NetworkManager nunca ejecuta tu archivo .ovpn o wg-quick tal cual. Entrega el archivo a un analizador, el analizador lo convierte al formato de conexión propio de NetworkManager y, a partir de ahí, el túnel se construye con ese objeto analizado: secretos, rutas, DNS y todo lo demás. Así que la pregunta útil no es por qué está roto el archivo, sino si se produjo el análisis y qué conservó.

Qué hace realmente la importación con el archivo

Para OpenVPN, el analizador vive en el paquete del plugin, y la conexión que crea apunta a un servicio D-Bus como org.freedesktop.NetworkManager.openvpn. Sin plugin no hay analizador: nmcli desconoce el tipo y la lista gráfica de añadir VPN puede no mostrar ninguna entrada de importación. WireGuard se diferencia en un punto importante: NetworkManager tiene sus propios ajustes de WireGuard desde la serie 1.30, así que no hay un paquete de plugin aparte, pero el lector de wg-quick solo existe en compilaciones que lo incluyen.

En cualquier caso, el archivo se lee una vez. El resultado se escribe como keyfile en /etc/NetworkManager/system-connections/, con el nombre de la conexión, propiedad de root e ilegible para otros usuarios porque contiene el material de claves. Ese keyfile es ahora la conexión; editar después el .ovpn original no cambia nada.

Tres síntomas pertenecen a tres fases distintas. Que no haya entrada de importación o que el tipo sea desconocido significa que falta el plugin o la versión. Un error de importación que nombra una directiva significa que el analizador leyó el archivo y rechazó parte de él. Una conexión que existe pero nunca se activa significa que el objeto analizado está incompleto o que el servidor la rechaza. Decide cuál de los tres tienes antes de editar nada.

Confirma el plugin antes de depurar el perfil

Un plugin ausente parece exactamente un perfil corrupto, así que revisa primero el paquete. En Debian y Ubuntu el soporte de OpenVPN viene como network-manager-openvpn más un ayudante de escritorio; en Fedora los paquetes son NetworkManager-openvpn y NetworkManager-openvpn-gnome; en Arch es networkmanager-openvpn.

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

Luego importa desde una ruta absoluta: nmcli connection import type openvpn file /home/you/profile.ovpn. Las rutas relativas suelen funcionar, pero un shell que ha cambiado de directorio convierte una importación rápida en un desvío. Para WireGuard, comprueba nmcli --version y asegúrate de que el lado del kernel existe con modprobe wireguard; una importación que tiene éxito en una máquina sin el módulo te deja con una conexión cuyo dispositivo nunca aparece. La referencia de nmcli documenta el subcomando import y los nombres de tipo aceptados. Si type wireguard se rechaza de plano, la compilación es anterior a la función, y el paso correcto es un paquete de la distribución o un backport, no copiar la configuración a un directorio arbitrario y esperar que algo la lea.

Lee la conexión de OpenVPN, no el .ovpn

Una vez que la conexión existe, lee los ajustes analizados en lugar de releer el archivo: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Quieres el remote y el puerto, el transporte, el material de identidad (ca, cert, key, tls-auth o tls-crypt) y el método de autenticación. En un perfil con contraseña de clave privada, añade sudo nmcli --show-secrets connection show "Work VPN" y mira los secret flags: 0 es none, así que el secreto está en el keyfile; 1 es agent-owned; 2 es not-saved, lo que significa que nunca se escribe en el keyfile; 4 es not-required, lo que significa que no hace falta ningún secreto. Son bits, no una escala, así que 3 es simplemente agent-owned más not-saved. Un secreto que te pregunta una vez por sesión es agent-owned (1) con el agente pidiéndolo; no hay un número de flag aparte para eso. Un desajuste de flags es la razón habitual de que un perfil conecte desde el applet de escritorio y falle desde un script o al arrancar.

La forma más rápida de ver qué descartó el analizador es pedirle al plugin que vuelva a escribir el archivo y luego compararlo: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Las directivas que desaparecen en esa comparación no existirán al conectar. Los hooks son los sospechosos habituales: script-security, up, down y route-up esperan un script que se ejecute con privilegios elevados y deliberadamente no se trasladan. No bajes la verificación ni concedas privilegios extra para que una importación funcione; una opción no admitida suele reflejar el conjunto de funciones del plugin y no un servidor inalcanzable. Lleva ese comportamiento a un script dispatcher de NetworkManager o a una política del servidor.

Confirma también que sobrevivieron los campos de identidad: la referencia de CA, remote-cert-tls y cualquier comprobación de nombre en la que confiara el perfil. Una conexión que sube sin ellos puede estar hablando con lo que sea que responda en esa dirección.

Lee la conexión de WireGuard, no el archivo wg-quick

Un archivo wg-quick es un formato con semántica de shell; la conexión importada es un conjunto de ajustes. PrivateKey pasa a ser la clave privada de la interfaz, Address pasa a ser una o varias direcciones IPv4 e IPv6, DNS se asigna a las propiedades de resolver de NetworkManager, MTU se asigna a wireguard.mtu (el valor predeterminado propio de wg-quick es 1420), y cada bloque peer se convierte en una entrada peer con clave pública, endpoint, IP permitidas y keepalive persistente. Imprime lo que se guardó con nmcli --show-secrets connection show wg0; si la lista de peers no aparece en esa salida, lee el keyfile:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

Lo que no sobrevive es la mitad de shell de wg-quick. PreUp, PostUp, PreDown, PostDown y Table son comportamiento de esa herramienta, no atributos de una interfaz WireGuard, así que nada los ejecuta tras una importación. Si el original usaba Table = off para dejar intacta la ruta predeterminada, las versiones recientes de NetworkManager exponen ip4-auto-default-route e ip6-auto-default-route para el mismo propósito; configúralos explícitamente en lugar de suponer que la conexión se comporta como el script. Un hook que empujaba una ruta personalizada necesita esa ruta en los ajustes de enrutamiento de la conexión, o simplemente faltará.

Dale a la conexión exactamente un dueño

El fallo clásico de después es una conexión que funciona hasta el siguiente arranque y luego entra en bucle. Normalmente [email protected] seguía habilitado de un experimento anterior, o un cliente del proveedor lanzaba su propio demonio, y dos dueños escribían rutas y DNS para el mismo destino. NetworkManager configura el resolver por su propio camino, wg-quick escribe mediante resolvconf, y gana el último que escribe: la resolución de nombres funciona, luego se detiene y luego vuelve a funcionar. Comprueba systemctl status wg-quick@wg0, nmcli connection show --active y ip link show type wireguard, y luego desactiva el segundo dueño en lugar de ajustar su métrica.

Si de verdad necesitas ambos, dales interfaces separadas y IP permitidas disjuntas, y deja que exactamente uno de ellos instale la ruta predeterminada. Dos rutas predeterminadas con métricas distintas no son un túnel dividido; es una carrera que decide el servicio que arranca segundo. Y tras una reconexión, inspecciona de nuevo el estado aplicado: una edición manual del resolver que hace que todo funcione no es prueba de que la importación esté completa.

Verifica con tráfico y sobrevive a un reinicio

Levanta la conexión con nmcli connection up "Work VPN" y luego lee estado, dirección y rutas en lugar de fiarte del icono: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default y una consulta real de un nombre que solo resuelve dentro del túnel. Un handshake o un ping correcto solo demuestra que la criptografía funciona; no dice nada del reenvío, de los prefijos del túnel dividido ni del DNS privado, que son las partes que suelen romperse.

Luego reinicia y repítelo. El comportamiento de autoconnect, una interfaz renombrada y un plugin que se carga después del dispositivo son fallos que solo ves en un arranque limpio. journalctl -u NetworkManager -b --no-pager | tail -n 40 muestra qué hizo el demonio con esta conexión en este arranque. Para un segundo escritorio, copia el keyfile y mantenlo propiedad de root con modo 600, o usa nmcli connection export para OpenVPN y vuelve a importar el .ovpn resultante: la ruta de exportación no tiene equivalente en WireGuard, así que esa dirección es una copia de archivo o una importación nueva desde el original protegido.

Versión corta, en orden: confirma el plugin o la versión de NetworkManager, importa desde una ruta absoluta, lee los ajustes analizados incluidos los secret flags, compara la exportación de OpenVPN con el original, revisa hooks y rutas en el lado de WireGuard, desactiva cualquier segundo dueño y luego verifica tras un reinicio una consulta de nombres y la tabla de rutas. Cuando una conexión supera todo eso, el archivo de perfil que la inició puede volver al almacenamiento protegido.