A importación en NetworkManager falla con ficheiros OpenVPN e WireGuard

Escollín Importar desde ficheiro… na Configuración de GNOME, escollín un perfil que funciona co cliente do provedor, e o diálogo pechouse sen engadir nada á lista. Nun segundo portátil a importación completouse, a conexión apareceu co nome do perfil e despois fallou na primeira solicitude de autenticación. NetworkManager nunca executa o teu ficheiro .ovpn ou wg-quick tal e como está. Entrega o ficheiro a un analizador, o analizador convérteo no formato de conexión propio de NetworkManager e, a partir de aí, o túnel constrúese a partir dese obxecto analizado: segredos, rutas, DNS e todo o demais. Así que a pregunta útil non é por que está roto o ficheiro, senón se se produciu a análise e que conservou.

Que fai realmente a importación co ficheiro

Para OpenVPN, o analizador vive no paquete do plugin, e a conexión que crea apunta a un servizo D-Bus como org.freedesktop.NetworkManager.openvpn. Sen plugin non hai analizador: nmcli descoñece o tipo e a lista gráfica de engadir VPN pode non amosar ningunha entrada de importación. WireGuard difire nun punto importante: NetworkManager ten os seus propios axustes de WireGuard desde a serie 1.30, así que non hai un paquete de plugin aparte, pero o lector de wg-quick só existe en compilacións que o inclúen.

En calquera caso, o ficheiro lese unha vez. O resultado escríbese como keyfile en /etc/NetworkManager/system-connections/, co nome da conexión, propiedade de root e ilexible para outros usuarios porque contén o material das chaves. Ese keyfile é agora a conexión; editar despois o .ovpn orixinal non cambia nada.

Tres síntomas pertencen a tres fases distintas. Que non haxa entrada de importación ou que o tipo sexa descoñecido significa que falta o plugin ou a versión. Un erro de importación que nomea unha directiva significa que o analizador leu o ficheiro e rexeitou parte del. Unha conexión que existe pero nunca se activa significa que o obxecto analizado está incompleto ou que o servidor a rexeita. Decide cal dos tres tes antes de editar nada.

Confirma o plugin antes de depurar o perfil

Un plugin ausente parece exactamente un perfil corrupto, así que revisa primeiro o paquete. En Debian e Ubuntu o soporte de OpenVPN vén como network-manager-openvpn máis un axudante de escritorio; en Fedora os paquetes son NetworkManager-openvpn e NetworkManager-openvpn-gnome; en Arch é networkmanager-openvpn.

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

Despois importa desde unha ruta absoluta: nmcli connection import type openvpn file /home/you/profile.ovpn. As rutas relativas adoitan funcionar, pero unha shell que cambiou de directorio converte unha importación rápida nun desvío. Para WireGuard, comproba nmcli --version e asegúrate de que o lado do kernel existe con modprobe wireguard; unha importación que ten éxito nunha máquina sen o módulo déixache cunha conexión cuxo dispositivo nunca aparece. A referencia de nmcli documenta o subcomando import e os nomes de tipo aceptados. Se type wireguard se rexeita de plano, a compilación é anterior á función, e o paso correcto é un paquete da distribución ou un backport — non copiar a configuración a un directorio arbitrario e esperar que algo a lea.

Le a conexión de OpenVPN, non o .ovpn

Unha vez que a conexión existe, le os axustes analizados en lugar de reler o ficheiro: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Queres o remote e o porto, o transporte, o material de identidade — ca, cert, key, tls-auth ou tls-crypt — e o método de autenticación. Nun perfil con contrasinal de clave privada, engade sudo nmcli --show-secrets connection show "Work VPN" e mira as secret flags: 0 é none, así que o segredo está no keyfile; 1 é agent-owned; 2 é not-saved, o que significa que nunca se escribe no keyfile; 4 é not-required, o que significa que non fai falta ningún segredo. Son bits, non unha escala, así que 3 é simplemente agent-owned máis not-saved. Un segredo que che pregunta unha vez por sesión é agent-owned (1) co agente pedíndoo; non hai un número de flag aparte para iso. Un desaxuste de flags é a razón habitual de que un perfil conecte desde o applet de escritorio e falle desde un script ou ao arrincar.

A forma máis rápida de ver que descartou o analizador é pedirlle ao plugin que volva escribir o ficheiro e despois comparalo: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. As directivas que desaparecen nesa comparación non existirán ao conectar. Os hooks son os sospeitosos habituais — script-security, up, down e route-up esperan un script executado con privilexios elevados e deliberadamente non se trasladan. Non baixes a verificación nin concedas privilexios extra para que unha importación funcione; unha opción non admitida reflicte normalmente o conxunto de funcións do plugin e non un servidor inalcanzable. Leva ese comportamento a un script dispatcher de NetworkManager ou a unha política do servidor.

Confirma tamén que sobreviviron os campos de identidade: a referencia da CA, remote-cert-tls e calquera comprobación de nome na que confiase o perfil. Unha conexión que sobe sen eles pode estar falando co que sexa que responda nese enderezo.

Le a conexión de WireGuard, non o ficheiro wg-quick

Un ficheiro wg-quick é un formato con semántica de shell; a conexión importada é un conxunto de axustes. PrivateKey pasa a ser a clave privada da interface, Address pasa a ser un ou varios enderezos IPv4 e IPv6, DNS mapéase ás propiedades de resolver de NetworkManager, MTU mapéase a wireguard.mtu (o valor predeterminado propio de wg-quick é 1420), e cada bloque peer convértese nunha entrada peer con clave pública, endpoint, IPs permitidas e keepalive persistente. Imprime o que se gardou con nmcli --show-secrets connection show wg0; se a lista de peers non aparece nesa saída, le o keyfile:

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

O que non sobrevive é a metade de shell de wg-quick. PreUp, PostUp, PreDown, PostDown e Table son comportamento desa ferramenta, non atributos dunha interface WireGuard, así que nada os executa tras unha importación. Se o orixinal usaba Table = off para deixar intacta a ruta predeterminada, as versións recentes de NetworkManager expoñen ip4-auto-default-route e ip6-auto-default-route para o mesmo propósito; configúraos explicitamente en lugar de supor que a conexión se comporta como o script. Un hook que empurraba unha ruta personalizada necesita esa ruta nos axustes de encamiñamento da conexión, ou simplemente faltará.

Dálle á conexión exactamente un dono

O fallo clásico de despois é unha conexión que funciona ata o seguinte arrinque e logo entra en bucle. Normalmente [email protected] seguía activo dun experimento anterior, ou un cliente do provedor lanzaba o seu propio daemon, e dous donos escribían rutas e DNS para o mesmo destino. NetworkManager configura o resolver polo seu propio camiño, wg-quick escribe mediante resolvconf, e gaña o último que escribe — a resolución de nomes funciona, logo detense e logo volve funcionar. Comproba systemctl status wg-quick@wg0, nmcli connection show --active e ip link show type wireguard, e despois desactiva o segundo dono en lugar de axustar a súa métrica.

Se de verdade necesitas ambos, dálles interfaces separadas e IPs permitidas disxuntas, e deixa que exactamente un deles instale a ruta predeterminada. Dúas rutas predeterminadas con métricas distintas non son un túnel dividido; é unha carreira que decide o servizo que arrinca segundo. E tras unha reconexión, inspecciona de novo o estado aplicado — unha edición manual do resolver que fai que todo funcione non é proba de que a importación estea completa.

Verifica con tráfico e sobrevive a un reinicio

Levanta a conexión con nmcli connection up "Work VPN" e despois le estado, enderezo e rutas en lugar de fiarte da icona: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default e unha consulta real dun nome que só resolve dentro do túnel. Un handshake ou un ping correcto só demostra que a criptografía funciona; non di nada sobre o reenvío, os prefixos do túnel dividido nin o DNS privado, que son as partes que adoitan romper.

Despois reinicia e repíteo. O comportamento de autoconnect, unha interface renomeada e un plugin que se carga despois do dispositivo son fallos que só ves nun arrinque limpo. journalctl -u NetworkManager -b --no-pager | tail -n 40 amosa que fixo o daemon con esta conexión neste arrinque. Para un segundo escritorio, copia o keyfile e manteno propiedade de root con modo 600, ou usa nmcli connection export para OpenVPN e volve importar o .ovpn resultante — a ruta de exportación non ten equivalente en WireGuard, así que esa dirección é unha copia de ficheiro ou unha importación nova desde o orixinal protexido.

Versión curta, por orde: confirma o plugin ou a versión de NetworkManager, importa desde unha ruta absoluta, le os axustes analizados incluídas as secret flags, compara a exportación de OpenVPN co orixinal, revisa hooks e rutas no lado de WireGuard, desactiva calquera segundo dono e despois verifica tras un reinicio unha consulta de nomes e a táboa de rutas. Cando unha conexión supera todo iso, o ficheiro de perfil que a iniciou pode volver ao almacenamento protexido.