Keyfile oder Netplan: Wo ist das VPN-Profil wirklich gespeichert?

Die importierte Datei zu finden ist der leichte Teil und oft der falsche Einstieg. Entscheidend ist, welche Datei NetworkManager heute als gespeicherte Verbindung liest, und das hängt von einer Verbindungskennung sowie dem Konfigurations-Backend ab, das die installierten Pakete tatsächlich verwenden. Wer den Import bearbeitet, bevor diese Frage beantwortet ist, verwandelt ein funktionierendes VPN in zwei halbrichtige Konfigurationen.

Die importierte Datei ist nicht das gespeicherte Profil

Drei Namen geistern durch jedes VPN-Problem: der Verbindungsname, der Dateiname des Imports und die virtuelle Schnittstelle, die beim Aufbau des Tunnels erscheint. Keiner davon bezeichnet die gespeicherte Konfiguration, und ein Verbindungsname lässt sich ändern, während die dahinterliegende Datei ihre ursprüngliche Kennung behält.

Beginnen Sie mit einer reinen Leseinventur und wählen Sie das gewünschte VPN anhand der Kennung statt anhand der Bezeichnung:

nmcli -f NAME,UUID,TYPE connection show

Lassen Sie Endpunkt-Hostnamen und Identitätsbezeichnungen aus jeder Inventur heraus, die Sie in ein Ticket kopieren. Nützlich sind Typ und Kennung; der Rest ist Kontext, den ein Fremder nicht braucht. Schwärzen Sie den Rest vor dem Teilen und sagen Sie, dass Sie es getan haben, damit sich niemand fragt, was die Lücken bedeuten.

Keyfile-Speicherorte bedeuten nicht dasselbe

Beim nativen Keyfile-Plugin können Verbindungsdateien in drei Verzeichnissen auftauchen, und der Unterschied zwischen ihnen ist Persistenz, nicht Bequemlichkeit.

Eine Änderung an der Laufzeitkopie wirkt erfolgreich bis zum nächsten Start; dann verdampft die Änderung und die Datei sieht rätselhaft zurückgesetzt aus. Die Bearbeitung der vom Paket gelieferten Kopie funktioniert, bis ein Upgrade sie ersetzt – eine langsamere und verwirrendere Version derselben Lektion.

Die Keyfile-Dokumentation ergänzt ein Detail, das man respektieren sollte: Diese Dateien können private Schlüssel und Passphrasen enthalten, und NetworkManager ignoriert jede Keyfile, die andere Benutzer als root lesen oder schreiben können. Erweiterte Verzeichnisrechte, um nach einer Einstellung zu stöbern, zerstören genau das Ladeverhalten, das Sie untersuchen wollten.

Wenn Netplan die Persistenz besitzt

Unter Ubuntu ändert die in der Netplan-Dokumentation beschriebene NetworkManager-Integration, verfügbar ab 23.10, den Ort der dauerhaften Kopie. Für nicht temporäre Verbindungen schreibt sie /etc/netplan/90-NM-<connection UUID>.yaml und erzeugt ein flüchtiges NetworkManager-Profil unter /run/NetworkManager/system-connections/.

Das ist eine Distribution-Integration, keine Regel für jede NetworkManager-Installation. Bestätigen Sie, dass die installierten Pakete sie tatsächlich nutzen, bevor Sie nach einer YAML-Datei suchen. Denken Sie auch daran, dass ein Laufzeitprofil eine generierte Darstellung von etwas anderem sein kann statt der Quelle, die es zu bearbeiten lohnt. Zwei Befehle der Prüfung sparen eine Stunde Bearbeitung der falschen Datei.

Das dokumentierte Beispiel speichert eine OpenVPN-Verbindung über den Netplan-Typ nm-devices mit Durchreichdaten von NetworkManager. Dass Netplan ein bestimmtes VPN-Feld nicht eigens interpretiert, heißt nicht, dass Ihr gespeichertes VPN verloren ist; es heißt, dass das Feld als undurchsichtige Daten reist.

Flüchtige Schnittstellen sind keine Profile

Die Aktivierung erzeugt temporäre virtuelle Verbindungen und Schnittstellen, die nie zur Persistenz gedacht waren. Die Integration schreibt dafür bewusst keine neue YAML-Datei, ihre Abwesenheit in /etc/netplan sagt also nichts darüber aus, ob das übergeordnete Profil gespeichert ist.

Wenn Sie eine Datei jagen, die erscheint und verschwindet, betrachten Sie wahrscheinlich eine davon und nicht Ihre Konfiguration. Prüfen Sie, ob sie einen Neustart überlebt, bevor Sie aus ihrem Inhalt Schlüsse ziehen. Eine Laufzeitdatei, die beim Reboot verschwindet, sagt Ihnen, dass sie nie die Quelle war, und diese einzelne Beobachtung lenkt die ganze Untersuchung um. Sie erklärt auch, warum eine Änderung damals erfolgreich aussah.

Geheimnisse und Eigentümerschaft

Ein Profil kann auf ein Zertifikat oder einen Schlüssel verweisen, der ganz woanders liegt, und ein Passwort kann NetworkManager gehören, von einem geheimen Agenten der Benutzersitzung stammen oder bewusst nicht gespeichert sein. Eine einzelne Datei zu finden klärt daher sehr wenig darüber, was ein unbeaufsichtigter Start braucht.

Prüfen Sie die Verweise und die Geheimnis-Flags, ohne geheime Werte auszugeben. Eine Desktop-Anmeldung kann einen Agenten verfügbar machen, der beim Booten fehlte, und eine generierte Laufzeitdatei zu kopieren reproduziert diesen Agenten nicht. Das praktische Symptom ist ein Tunnel, der verbindet, wenn sich jemand anmeldet, und scheitert, wenn die Maschine allein startet. Dieses Muster deutet auf Geheimnis-Eigentümerschaft hin, nicht auf Routing.

Nehmen Sie genehmigte Änderungen über den Manager vor, dem die Verbindung gehört, und prüfen Sie danach sowohl die gespeicherte Kennung als auch die effektive Verbindung. Halten Sie einen einzigen persistenten Eigentümer, denn den Import, eine generierte Keyfile und eine YAML-Quelle unabhängig zu bearbeiten hinterlässt drei konkurrierende Erklärungen dafür, was der nächste Reconnect nutzt. Wählen Sie die, die tatsächlich persistiert, bearbeiten Sie nur diese und notieren Sie im Ticket, welche Datei Sie als maßgeblich behandelt haben. Die nächste Person wird Ihnen für eine Zeile Herkunft danken.