NetworkManager-Import bei OpenVPN- und WireGuard-Dateien schlägt fehl

Ich wählte Aus Datei importieren… in den GNOME-Einstellungen, nahm ein Profil, das mit dem Client des Herstellers funktioniert, und der Dialog schloss sich, ohne etwas zur Liste hinzuzufügen. Auf einem zweiten Laptop war der Import abgeschlossen, die Verbindung erschien unter dem Namen des Profils, und dann scheiterte sie an der ersten Authentifizierungsabfrage. NetworkManager führt Ihre .ovpn- oder wg-quick-Datei nie unverändert aus. Er übergibt die Datei an einen Parser, der Parser verwandelt sie in NetworkManagers eigenes Verbindungsformat, und von da an wird der Tunnel aus diesem geparsten Objekt aufgebaut — Secrets, Routen, DNS und alles Übrige. Die nützliche Frage ist also nicht, warum die Datei defekt ist, sondern ob das Parsen stattfand und was dabei erhalten blieb.

Was der Import tatsächlich mit der Datei macht

Für OpenVPN, lebt der Parser im Plugin-Paket, und die Verbindung, die er anlegt, verweist auf einen D-Bus-Dienst wie org.freedesktop.NetworkManager.openvpn. Kein Plugin, kein Parser: Der Typ ist nmcli unbekannt, und die grafische Liste zum Hinzufügen einer VPN-Verbindung zeigt womöglich gar keinen Import-Eintrag. WireGuard unterscheidet sich in einem wichtigen Punkt — NetworkManager bringt seit der 1.30-Reihe eigene WireGuard-Einstellungen mit, es gibt also kein separates Plugin-Paket, aber der wg-quick-Leser existiert nur in Builds, die ihn mitliefern.

So oder so wird die Datei einmal gelesen. Das Ergebnis wird als Keyfile unter /etc/NetworkManager/system-connections/ geschrieben, benannt nach der Verbindung, gehört root und ist für andere Benutzer unlesbar, weil es das Schlüsselmaterial enthält. Dieses Keyfile ist jetzt die Verbindung; eine spätere Bearbeitung der ursprünglichen .ovpn ändert nichts.

Drei Symptome gehören zu drei verschiedenen Phasen. Kein Import-Eintrag oder ein unbekannter Typ bedeutet, dass das Plugin oder die Version fehlt. Ein Importfehler, der eine Direktive nennt, bedeutet, dass der Parser die Datei gelesen und einen Teil davon verworfen hat. Eine Verbindung, die existiert, aber nie aktiviert wird, bedeutet, dass das geparste Objekt unvollständig ist oder die Serverseite sie ablehnt. Entscheiden Sie, welchen Fall Sie haben, bevor Sie irgendetwas bearbeiten.

Prüfen Sie das Plugin, bevor Sie das Profil debuggen

Ein fehlendes Plugin sieht genau wie ein beschädigtes Profil aus, also prüfen Sie zuerst das Paket. Unter Debian und Ubuntu wird die OpenVPN-Unterstützung als network-manager-openvpn plus ein Desktop-Helfer ausgeliefert; unter Fedora sind es die Pakete NetworkManager-openvpn und NetworkManager-openvpn-gnome; unter Arch ist es networkmanager-openvpn.

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

Importieren Sie dann über einen absoluten Pfad: nmcli connection import type openvpn file /home/you/profile.ovpn. Relative Pfade funktionieren meist, aber eine Shell, die das Verzeichnis gewechselt hat, macht aus einem schnellen Import einen Umweg. Prüfen Sie für WireGuard nmcli --version und stellen Sie sicher, dass die Kernelseite mit modprobe wireguard vorhanden ist; ein Import, der auf einer Maschine ohne das Modul gelingt, hinterlässt eine Verbindung, deren Gerät nie auftaucht. Die nmcli-Referenz dokumentiert das Unterkommando import und die akzeptierten Typnamen. Wird type wireguard rundweg abgelehnt, ist der Build älter als die Funktion, und der richtige Schritt ist ein Distributionspaket oder ein Backport — nicht das Kopieren der Konfiguration in ein beliebiges Verzeichnis in der Hoffnung, dass etwas sie liest.

Lesen Sie die OpenVPN-Verbindung, nicht die .ovpn

Sobald die Verbindung existiert, lesen Sie die geparsten Einstellungen statt die Datei erneut: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Sie wollen den Remote-Host und den Port, das Transportprotokoll, das Identitätsmaterial — ca, cert, key, tls-auth oder tls-crypt — und die Authentifizierungsmethode. Bei einem Profil mit Passwort für den privaten Schlüssel ergänzen Sie sudo nmcli --show-secrets connection show "Work VPN" und schauen sich die Secret-Flags an: 0 ist none, das Secret liegt also im Keyfile; 1 ist agent-owned; 2 ist not-saved, wird also nie ins Keyfile geschrieben; 4 ist not-required, es wird also gar kein Secret benötigt. Es sind Bits, keine Skala, 3 ist also einfach agent-owned plus not-saved. Ein Secret, das einmal pro Sitzung nachfragt, ist agent-owned (1), wobei der Agent danach fragt; eine eigene Flag-Nummer dafür gibt es nicht. Ein Flag-Mismatch ist der übliche Grund, warum ein Profil im Desktop-Applet verbindet und per Skript oder beim Booten scheitert.

Am schnellsten sehen Sie, was der Parser verworfen hat, wenn Sie das Plugin bitten, die Datei zurückzuschreiben, und dann vergleichen: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Direktiven, die in diesem Diff verschwinden, existieren zur Verbindungszeit nicht. Hooks sind die üblichen Verdächtigen — script-security, up, down und route-up erwarten ein Skript, das mit erhöhten Rechten läuft, und werden bewusst nicht übernommen. Senken Sie nicht die Verifikation und geben Sie keine zusätzlichen Rechte, damit ein Import gelingt; eine nicht unterstützte Option spiegelt meist den Funktionsumfang des Plugins wider und nicht einen unerreichbaren Server. Verlegen Sie dieses Verhalten in ein NetworkManager-Dispatcher-Skript oder in eine server-seitige Policy.

Prüfen Sie außerdem, ob die Identitätsfelder überlebt haben: die CA-Referenz, remote-cert-tls und jede Namensprüfung, auf die sich das Profil stützte. Eine Verbindung, die ohne sie hochkommt, spricht womöglich mit irgendetwas, das auf dieser Adresse antwortet.

Lesen Sie die WireGuard-Verbindung, nicht die wg-quick-Datei

Eine wg-quick-Datei ist ein Format mit Shell-Semantik; die importierte Verbindung ist eine Menge von Einstellungen. PrivateKey wird zum privaten Schlüssel des Interfaces, Address wird zu einer oder mehreren IPv4- und IPv6-Adressen, DNS bildet auf die Resolver-Eigenschaften von NetworkManager ab, MTU bildet auf wireguard.mtu ab (der eigene Standard von wg-quick ist 1420), und jeder Peer-Block wird zu einem Peer-Eintrag mit öffentlichem Schlüssel, Endpoint, erlaubten IPs und persistentem Keepalive. Lassen Sie sich ausgeben, was gespeichert wurde, mit nmcli --show-secrets connection show wg0; erscheint die Peer-Liste in dieser Ausgabe nicht, lesen Sie das Keyfile:

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

Nicht überlebt die Shell-Hälfte von wg-quick. PreUp, PostUp, PreDown, PostDown und Table sind Verhalten dieses Werkzeugs, keine Attribute eines WireGuard-Interfaces, also führt sie nach einem Import nichts aus. Wenn das Original Table = off nutzte, um die Default-Route unangetastet zu lassen, bieten neuere NetworkManager-Versionen ip4-auto-default-route und ip6-auto-default-route für denselben Zweck; setzen Sie sie ausdrücklich, statt anzunehmen, die Verbindung verhalte sich wie das Skript. Ein Hook, der eine eigene Route gesetzt hat, braucht diese Route in den Routing-Einstellungen der Verbindung, sonst fehlt sie schlicht.

Geben Sie der Verbindung genau einen Besitzer

Der klassische Folgefehler ist eine Verbindung, die bis zum nächsten Neustart funktioniert und dann in einer Schleife hängt. Meist war [email protected] aus einem früheren Versuch noch aktiviert, oder ein Hersteller-Client startete seinen eigenen Daemon, und zwei Besitzer schrieben Routen und DNS für dasselbe Ziel. NetworkManager setzt den Resolver über seinen eigenen Weg, wg-quick schreibt über resolvconf, und der letzte Schreiber gewinnt — die Namensauflösung funktioniert also, dann hört sie auf, dann funktioniert sie wieder. Prüfen Sie systemctl status wg-quick@wg0, nmcli connection show --active und ip link show type wireguard und deaktivieren Sie dann den zweiten Besitzer, statt an dessen Metrik zu drehen.

Wenn Sie wirklich beide brauchen, geben Sie ihnen getrennte Interfaces und disjunkte erlaubte IPs und lassen Sie genau einen von ihnen die Default-Route installieren. Zwei Default-Routen mit unterschiedlichen Metriken sind kein Split-Tunnel; es ist ein Wettlauf, den der Dienst entscheidet, der als zweites startet. Und prüfen Sie nach einem Reconnect den angewendeten Zustand erneut — eine einmalige manuelle Resolver-Änderung, die alles zum Laufen bringt, ist kein Beweis, dass der Import vollständig ist.

Prüfen Sie mit Traffic und überstehen Sie einen Neustart

Bringen Sie die Verbindung mit nmcli connection up "Work VPN" hoch und lesen Sie dann Zustand, Adresse und Routen, statt dem Symbol zu vertrauen: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default und eine echte Abfrage eines Namens, der nur im Tunnel aufgelöst wird. Ein Handshake oder ein erfolgreicher Ping beweist nur, dass die Krypto funktioniert; über Forwarding, Split-Tunnel-Präfixe oder privates DNS sagt er nichts, und genau das bricht üblicherweise.

Dann starten Sie neu und wiederholen es. Autoconnect-Verhalten, ein umbenanntes Interface und ein Plugin, das erst nach dem Gerät lädt, sind alles Fehler, die Sie nur bei einem frischen Boot sehen. journalctl -u NetworkManager -b --no-pager | tail -n 40 zeigt, was der Daemon in diesem Boot mit dieser Verbindung gemacht hat. Für einen zweiten Desktop kopieren Sie das Keyfile und halten es in root-Besitz mit Modus 600, oder Sie nutzen nmcli connection export für OpenVPN und importieren die entstehende .ovpn erneut — für den Exportweg gibt es kein WireGuard-Äquivalent, diese Richtung ist also eine Dateikopie oder ein frischer Import aus dem geschützten Original.

Kurzfassung, in dieser Reihenfolge: Plugin- oder NetworkManager-Version bestätigen, über einen absoluten Pfad importieren, die geparsten Einstellungen samt Secret-Flags lesen, den OpenVPN-Export mit dem Original vergleichen, Hooks und Routen auf der WireGuard-Seite prüfen, jeden zweiten Besitzer deaktivieren, dann nach einem Neustart eine Namensauflösung und die Routentabelle verifizieren. Wenn eine Verbindung all das besteht, kann die Profildatei, die sie gestartet hat, zurück in den geschützten Speicher.