Importeren in NetworkManager mislukt bij OpenVPN- en WireGuard-bestanden

Ik koos Importeren uit bestand… in GNOME-instellingen, koos een profiel dat met de client van de leverancier werkt, en de dialoog sloot zonder iets aan de lijst toe te voegen. Op een tweede laptop was de import wel klaar, verscheen de verbinding onder de naam van het profiel, en vervolgens faalde ze bij de eerste authenticatievraag. NetworkManager voert je .ovpn- of wg-quick-bestand nooit ongewijzigd uit. Het geeft het bestand aan een parser, de parser zet het om naar NetworkManagers eigen verbindingsformaat, en vanaf dat moment wordt de tunnel gebouwd uit dat geparseerde object — secrets, routes, DNS en al het overige. De nuttige vraag is dus niet waarom het bestand stuk is, maar of het parsen is gebeurd en wat er is overgebleven.

Wat de import werkelijk met het bestand doet

Voor OpenVPN zit de parser in het plugin-pakket, en de verbinding die hij aanmaakt wijst naar een D-Bus-dienst zoals org.freedesktop.NetworkManager.openvpn. Geen plugin, geen parser: het type is onbekend voor nmcli, en de grafische lijst om een VPN toe te voegen toont misschien helemaal geen import-item. WireGuard verschilt op één belangrijk punt — NetworkManager heeft sinds de 1.30-reeks eigen WireGuard-instellingen, dus er is geen apart plugin-pakket, maar de wg-quick-lezer bestaat alleen in builds die hem meeleveren.

Hoe dan ook wordt het bestand één keer gelezen. Het resultaat wordt als keyfile geschreven onder /etc/NetworkManager/system-connections/, genoemd naar de verbinding, eigendom van root en onleesbaar voor andere gebruikers omdat het het sleutelmateriaal bevat. Die keyfile is nu de verbinding; later het oorspronkelijke .ovpn bewerken verandert niets.

Drie symptomen horen bij drie verschillende fasen. Geen import-item of een onbekend type betekent dat de plugin of versie ontbreekt. Een importfout die een directive noemt betekent dat de parser het bestand heeft gelezen en een deel ervan heeft afgewezen. Een verbinding die bestaat maar nooit activeert betekent dat het geparseerde object onvolledig is of dat de serverkant hem weigert. Bepaal welk geval je hebt voordat je iets bewerkt.

Controleer de plugin voordat je het profiel debugt

Een ontbrekende plugin ziet er precies zo uit als een beschadigd profiel, dus controleer eerst het pakket. Op Debian en Ubuntu wordt OpenVPN-ondersteuning geleverd als network-manager-openvpn plus een desktop-helper; op Fedora zijn dat de pakketten NetworkManager-openvpn en NetworkManager-openvpn-gnome; op Arch is het networkmanager-openvpn.

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

Importeer dan via een absoluut pad: nmcli connection import type openvpn file /home/you/profile.ovpn. Relatieve paden werken meestal, maar een shell die van map is gewisseld maakt van een snelle import een omweg. Controleer voor WireGuard nmcli --version en zorg dat de kernelkant bestaat met modprobe wireguard; een import die slaagt op een machine zonder de module laat je achter met een verbinding waarvan het apparaat nooit verschijnt. De nmcli-referentie documenteert het subcommando import en de geaccepteerde typenamen. Wordt type wireguard botweg geweigerd, dan is de build ouder dan de functie, en de juiste stap is een distributiepakket of backport — niet de configuratie naar een willekeurige map kopiëren en hopen dat iets hem leest.

Lees de OpenVPN-verbinding, niet de .ovpn

Zodra de verbinding bestaat, lees je de geparseerde instellingen in plaats van het bestand opnieuw: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Je wilt de remote en poort, het transport, het identiteitsmateriaal — ca, cert, key, tls-auth of tls-crypt — en de authenticatiemethode. Voeg bij een profiel met een wachtwoord voor de privésleutel sudo nmcli --show-secrets connection show "Work VPN" toe en kijk naar de secret-flags: 0 is none, dus het secret staat in de keyfile; 1 is agent-owned; 2 is not-saved, wat betekent dat het nooit naar de keyfile wordt geschreven; 4 is not-required, wat betekent dat er helemaal geen secret nodig is. Het zijn bits, geen schaal, dus 3 is simpelweg agent-owned plus not-saved. Een secret dat je één keer per sessie vraagt is agent-owned (1), waarbij de agent erom vraagt; een apart flagnummer daarvoor bestaat niet. Een flag-mismatch is de gebruikelijke reden dat een profiel vanaf de desktop-applet verbindt en vanuit een script of bij het opstarten faalt.

De snelste manier om te zien wat de parser heeft laten vallen, is de plugin vragen het bestand terug te schrijven en dan te diffen: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Directives die in die diff verdwijnen, bestaan op verbindingstijd niet. Hooks zijn de gebruikelijke verdachten — script-security, up, down en route-up verwachten een script dat met verhoogde rechten draait en worden bewust niet overgenomen. Verlaag de verificatie niet en geef geen extra rechten om een import te laten slagen; een niet-ondersteunde optie weerspiegelt meestal de functieset van de plugin en niet een onbereikbare server. Verplaats dat gedrag naar een NetworkManager-dispatcherscript of naar beleid aan de serverkant.

Controleer ook of de identiteitsvelden het hebben overleefd: de CA-referentie, remote-cert-tls en elke naamcontrole waarop het profiel vertrouwde. Een verbinding die zonder die dingen omhoogkomt, praat misschien met wat er op dat adres antwoordt.

Lees de WireGuard-verbinding, niet het wg-quick-bestand

Een wg-quick-bestand is een formaat met shell-semantiek; de geïmporteerde verbinding is een set instellingen. PrivateKey wordt de privésleutel van de interface, Address wordt een of meer IPv4- en IPv6-adressen, DNS mapt op de resolver-eigenschappen van NetworkManager, MTU mapt op wireguard.mtu (de eigen standaard van wg-quick is 1420), en elk peer-blok wordt een peer-item met publieke sleutel, endpoint, toegestane IP's en persistente keepalive. Print wat er is opgeslagen met nmcli --show-secrets connection show wg0; verschijnt de peer-lijst niet in die uitvoer, lees dan de keyfile:

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

Wat niet overleeft, is de shell-helft van wg-quick. PreUp, PostUp, PreDown, PostDown en Table zijn gedrag van dat gereedschap, geen attributen van een WireGuard-interface, dus niets voert ze uit na een import. Als het origineel Table = off gebruikte om de standaardroute met rust te laten, bieden recente NetworkManager-releases ip4-auto-default-route en ip6-auto-default-route voor hetzelfde doel; zet ze expliciet in plaats van aan te nemen dat de verbinding zich als het script gedraagt. Een hook die een aangepaste route pushte, heeft die route nodig in de routinginstellingen van de verbinding, anders ontbreekt hij gewoon.

Geef de verbinding precies één eigenaar

De klassieke vervolgstoring is een verbinding die werkt tot de volgende herstart en dan in een lus raakt. Meestal stond [email protected] nog aan uit een eerder experiment, of startte een leveranciersclient zijn eigen daemon, en schreven twee eigenaars routes en DNS voor dezelfde bestemming. NetworkManager zet de resolver via zijn eigen pad, wg-quick schrijft via resolvconf, en de laatste schrijver wint — dus naamresolutie werkt, stopt, en werkt weer. Controleer systemctl status wg-quick@wg0, nmcli connection show --active en ip link show type wireguard en schakel dan de tweede eigenaar uit in plaats van aan zijn metric te draaien.

Heb je ze echt allebei nodig, geef ze dan aparte interfaces en disjuncte toegestane IP's, en laat precies één van hen de standaardroute installeren. Twee standaardroutes met verschillende metrics is geen split tunnel; het is een race die wordt beslist door de dienst die als tweede start. En inspecteer na een reconnect de toegepaste toestand opnieuw — een eenmalige handmatige resolver-wijziging die dingen laat werken is geen bewijs dat de import compleet is.

Verifieer met verkeer en overleef een herstart

Breng de verbinding omhoog met nmcli connection up "Work VPN" en lees dan toestand, adres en routes in plaats van het pictogram te vertrouwen: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default, en een echte opzoeking van een naam die alleen binnen de tunnel resolveert. Een handshake of een geslaagde ping bewijst alleen dat de crypto werkt; hij zegt niets over forwarding, split-tunnel-prefixes of private DNS, en dat zijn de delen die meestal breken.

Herstart dan en herhaal het. Autoconnect-gedrag, een hernoemde interface en een plugin die na het apparaat laadt zijn allemaal storingen die je alleen bij een verse boot ziet. journalctl -u NetworkManager -b --no-pager | tail -n 40 toont wat de daemon in deze boot met deze verbinding deed. Kopieer voor een tweede desktop de keyfile en houd hem eigendom van root met modus 600, of gebruik nmcli connection export voor OpenVPN en importeer de resulterende .ovpn opnieuw — voor het exportpad bestaat geen WireGuard-equivalent, dus die richting is een bestandskopie of een verse import uit het beschermde origineel.

Korte versie, in volgorde: bevestig de plugin- of NetworkManager-versie, importeer via een absoluut pad, lees de geparseerde instellingen inclusief secret-flags, diff de OpenVPN-export tegen het origineel, controleer hooks en routes aan de WireGuard-kant, schakel elke tweede eigenaar uit, en verifieer na een herstart een naamopzoeking en de routetabel. Als een verbinding dat allemaal doorstaat, kan het profielbestand dat hem startte terug naar beschermde opslag.