A importação no NetworkManager falha com ficheiros OpenVPN e WireGuard

Escolhi Importar de ficheiro… nas Definições do GNOME, escolhi um perfil que funciona com o cliente do fornecedor, e a caixa de diálogo fechou sem acrescentar nada à lista. Num segundo portátil a importação ficou concluída, a ligação apareceu com o nome do perfil e depois falhou no primeiro pedido de autenticação. O NetworkManager nunca executa o seu ficheiro .ovpn ou wg-quick tal como está. Entrega o ficheiro a um analisador, o analisador converte-o no formato de ligação próprio do NetworkManager e, a partir daí, o túnel é construído a partir desse objeto analisado — segredos, rotas, DNS e tudo o resto. Portanto, a pergunta útil não é por que razão o ficheiro está avariado, mas se a análise aconteceu e o que conservou.

O que a importação faz realmente com o ficheiro

Para OpenVPN, o analisador vive no pacote do plugin, e a ligação que cria aponta para um serviço D-Bus como org.freedesktop.NetworkManager.openvpn. Sem plugin não há analisador: o tipo é desconhecido para o nmcli, e a lista gráfica de adicionar VPN pode não mostrar sequer uma entrada de importação. O WireGuard difere num ponto importante — o NetworkManager tem definições próprias de WireGuard desde a série 1.30, por isso não existe um pacote de plugin separado, mas o leitor de wg-quick só existe em compilações que o incluam.

De qualquer forma, o ficheiro é lido uma vez. O resultado é escrito como keyfile em /etc/NetworkManager/system-connections/, com o nome da ligação, propriedade de root e ilegível para outros utilizadores porque contém o material das chaves. Esse keyfile é agora a ligação; editar depois o .ovpn original não muda nada.

Três sintomas pertencem a três fases diferentes. Não haver entrada de importação ou o tipo ser desconhecido significa que falta o plugin ou a versão. Um erro de importação que nomeia uma diretiva significa que o analisador leu o ficheiro e rejeitou parte dele. Uma ligação que existe mas nunca ativa significa que o objeto analisado está incompleto ou que o servidor a recusa. Decida qual dos casos tem antes de editar seja o que for.

Confirme o plugin antes de depurar o perfil

Um plugin em falta parece exatamente um perfil corrompido, por isso verifique primeiro o pacote. No Debian e no Ubuntu o suporte de OpenVPN vem como network-manager-openvpn mais um auxiliar de ambiente de trabalho; no Fedora os pacotes são NetworkManager-openvpn e NetworkManager-openvpn-gnome; no Arch é networkmanager-openvpn.

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

Depois importe a partir de um caminho absoluto: nmcli connection import type openvpn file /home/you/profile.ovpn. Os caminhos relativos costumam funcionar, mas uma shell que mudou de diretório transforma uma importação rápida num desvio. Para o WireGuard, verifique nmcli --version e confirme que o lado do kernel existe com modprobe wireguard; uma importação que tem êxito numa máquina sem o módulo deixa-o com uma ligação cujo dispositivo nunca aparece. A referência do nmcli documenta o subcomando import e os nomes de tipo aceites. Se type wireguard for rejeitado de imediato, a compilação é anterior à funcionalidade, e o passo correto é um pacote da distribuição ou um backport — não copiar a configuração para um diretório arbitrário à espera que algo a leia.

Leia a ligação OpenVPN, não o .ovpn

Assim que a ligação existir, leia as definições analisadas em vez de reler o ficheiro: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Quer o remote e a porta, o transporte, o material de identidade — ca, cert, key, tls-auth ou tls-crypt — e o método de autenticação. Num perfil com palavra-passe de chave privada, acrescente sudo nmcli --show-secrets connection show "Work VPN" e olhe para as secret flags: 0 é none, portanto o segredo está no keyfile; 1 é agent-owned; 2 é not-saved, ou seja, nunca é escrito no keyfile; 4 é not-required, ou seja, não é preciso segredo nenhum. São bits, não uma escala, por isso 3 é simplesmente agent-owned mais not-saved. Um segredo que lhe pergunta uma vez por sessão é agent-owned (1), com o agente a pedi-lo; não há um número de flag separado para isso. Um desacordo de flags é a razão habitual para um perfil ligar a partir do applet do ambiente de trabalho e falhar a partir de um script ou no arranque.

A forma mais rápida de ver o que o analisador deixou cair é pedir ao plugin que escreva o ficheiro de volta e depois compará-lo: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. As diretivas que desaparecem nessa comparação não existirão na altura da ligação. Os hooks são os suspeitos habituais — script-security, up, down e route-up esperam um script executado com privilégios elevados e são deliberadamente não transportados. Não baixe a verificação nem conceda privilégios extra para que uma importação funcione; uma opção não suportada reflete normalmente o conjunto de funcionalidades do plugin e não um servidor inalcançável. Mude esse comportamento para um script dispatcher do NetworkManager ou para uma política do lado do servidor.

Confirme também que os campos de identidade sobreviveram: a referência da CA, remote-cert-tls e qualquer verificação de nome em que o perfil confiasse. Uma ligação que sobe sem eles pode estar a falar com o que quer que responda nesse endereço.

Leia a ligação WireGuard, não o ficheiro wg-quick

Um ficheiro wg-quick é um formato com semântica de shell; a ligação importada é um conjunto de definições. PrivateKey passa a ser a chave privada da interface, Address passa a ser um ou mais endereços IPv4 e IPv6, DNS mapeia para as propriedades de resolver do NetworkManager, MTU mapeia para wireguard.mtu (o valor predefinido do próprio wg-quick é 1420), e cada bloco peer torna-se uma entrada peer com chave pública, endpoint, IPs permitidos e keepalive persistente. Imprima o que foi guardado com nmcli --show-secrets connection show wg0; se a lista de peers não aparecer nessa saída, leia o keyfile:

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

O que não sobrevive é a metade de shell do wg-quick. PreUp, PostUp, PreDown, PostDown e Table são comportamento dessa ferramenta, não atributos de uma interface WireGuard, por isso nada os executa depois de uma importação. Se o original usava Table = off para deixar a rota predefinida em paz, versões recentes do NetworkManager expõem ip4-auto-default-route e ip6-auto-default-route para o mesmo fim; defina-os explicitamente em vez de assumir que a ligação se comporta como o script. Um hook que empurrava uma rota personalizada precisa dessa rota nas definições de encaminhamento da ligação, senão simplesmente faltará.

Dê à ligação exatamente um dono

A falha clássica de seguimento é uma ligação que funciona até ao arranque seguinte e depois entra em ciclo. Normalmente o [email protected] ainda estava ativo de uma experiência anterior, ou um cliente do fornecedor lançava o seu próprio daemon, e dois donos escreviam rotas e DNS para o mesmo destino. O NetworkManager define o resolver pelo seu próprio caminho, o wg-quick escreve através do resolvconf, e ganha o último que escreve — a resolução de nomes funciona, depois pára, depois funciona outra vez. Verifique systemctl status wg-quick@wg0, nmcli connection show --active e ip link show type wireguard e depois desative o segundo dono em vez de afinar a sua métrica.

Se precisar genuinamente de ambos, dê-lhes interfaces separadas e IPs permitidos disjuntos, e deixe exatamente um deles instalar a rota predefinida. Duas rotas predefinidas com métricas diferentes não são um túnel dividido; é uma corrida decidida pelo serviço que arranca em segundo. E depois de uma reconexão, inspecione novamente o estado aplicado — uma edição manual do resolver que faz as coisas funcionar não é prova de que a importação está completa.

Verifique com tráfego e sobreviva a um reinício

Levante a ligação com nmcli connection up "Work VPN" e depois leia estado, endereço e rotas em vez de confiar no ícone: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default e uma consulta real de um nome que só resolve dentro do túnel. Um handshake ou um ping bem-sucedido só prova que a criptografia funciona; não diz nada sobre encaminhamento, prefixos de túnel dividido ou DNS privado, que são as partes que costumam quebrar.

Depois reinicie e repita. O comportamento de autoconnect, uma interface renomeada e um plugin que carrega depois do dispositivo são falhas que só vê num arranque limpo. journalctl -u NetworkManager -b --no-pager | tail -n 40 mostra o que o daemon fez com esta ligação neste arranque. Para um segundo computador, copie o keyfile e mantenha-o com proprietário root e modo 600, ou use nmcli connection export para OpenVPN e reimporte o .ovpn resultante — o caminho de exportação não tem equivalente em WireGuard, por isso essa direção é uma cópia de ficheiro ou uma importação nova a partir do original protegido.

Versão curta, por ordem: confirme o plugin ou a versão do NetworkManager, importe a partir de um caminho absoluto, leia as definições analisadas incluindo as secret flags, compare a exportação OpenVPN com o original, verifique hooks e rotas do lado do WireGuard, desative qualquer segundo dono e depois verifique, após um reinício, uma consulta de nomes e a tabela de rotas. Quando uma ligação passa tudo isso, o ficheiro de perfil que a iniciou pode voltar ao armazenamento protegido.