Sie führen nmcli connection show aus und erwarten eine Liste von VPNs, bekommen aber jede Verbindung, die der Rechner je gespeichert hat, einschließlich einer Bridge und eines Hotspots. Das gesuchte VPN ist vielleicht dabei, vielleicht als etwas anderes als vpn typisiert oder gar keine NetworkManager-Verbindung. Um zu wissen, welcher dieser drei Fälle zutrifft, braucht es zwei Befehle.

Zwei Listen, zwei Fragen

connection show beantwortet, was NetworkManager gespeichert hat, und connection show --active beantwortet, was gerade an ein Gerät angeschlossen ist. Die erste Liste enthält inaktive Profile, und das ist Absicht: ein gespeichertes VPN, das ausgefallen ist, bleibt ein Profil, das Sie möglicherweise reparieren müssen. Verwechselt man beides, entsteht der Eindruck, ein Tunnel laufe, während nur seine Konfiguration existiert.

Wählen Sie Felder, statt die Standardtabelle zu lesen, denn die Standardausgabe verbirgt den Typ auf schmalen Terminals und bricht lange Namen um.

NAME, UUID und TYPE sind für den ersten Durchgang meist alles, was Sie brauchen, danach sehen Sie sich den einen Eintrag, der Sie interessiert, über die UUID an.

TYPE ist die Stelle mit den Überraschungen

OpenVPN Verbindungen, die über das Plugin verwaltet werden, erscheinen als Typ vpn, weil das Plugin ein Dienst innerhalb des allgemeinen VPN-Rahmens ist. Die native WireGuard-Unterstützung ist ein eigener vollwertiger Verbindungstyp, daher findet ein Filter auf vpn sie nicht. Eine Suche nach einem WireGuard-Tunnel, die nichts zurückgibt, ist meist ein Filterproblem und kein fehlendes Profil. Das ist ein architektonischer Unterschied, keine Namensmarotte.

Dasselbe gilt für andere Tunneltypen, die NetworkManager mit der Zeit nativ zu behandeln lernte, lesen Sie also die TYPE-Spalte, bevor Sie schließen, dass etwas fehlt.

Listen Sie alles auf und filtern Sie danach, dann erscheint das Profil.

Lesen Sie die UUID, nicht nur den Namen

Namen sind Etiketten, die Menschen bearbeiten, und zwei Profile können nach einem unachtsamen Import dasselbe teilen. Die UUID ist die Identität, auf die Befehle und Dateien verweisen. Wenn ein Eintrag doppelt aussieht, vergleichen Sie die UUID und die zugrunde liegenden Einstellungen, bevor Sie etwas löschen.

Aktivierungsbefehle akzeptieren beides, und genau deshalb ändert eine namensbasierte Gewohnheit irgendwann das falsche Profil.

Kopieren Sie die UUID in Ihre Notizen, wenn Sie etwas ändern, das Sie vielleicht rückgängig machen müssen.

Was ein gespeichertes Profil Ihnen nicht sagt

Ein gespeichertes Profil sagt nichts darüber, ob sein Tunnel steht, und eine aktive Verbindung sagt nichts darüber, ob der Verkehr darin funktioniert. Ein Tunnel, den wg-quick oder eine Service-Unit startet, ist überhaupt keine NetworkManager-Verbindung, daher fehlt er in beiden Listen, während die Schnittstelle offensichtlich Verkehr durchlässt. Prüfen Sie Schnittstelle und Routing-Tabelle, bevor Sie annehmen, das Profil fehle. Eine leere Liste beweist nur, dass NetworkManager nicht der Eigentümer ist.

Zwei Manager für dieselbe Schnittstelle sind die andere Variante dieses Problems, und sie erzeugt eine Liste, die richtig aussieht, während der Kernelzustand einem anderen gehört.

Ein Eigentümer pro Schnittstelle hält die Liste ehrlich, und die nmcli-Referenz dokumentiert, welche Felder jede Ansicht tatsächlich meldet.

Berichten, ohne Geheimnisse zu verraten

connection show mit einem Namen gibt Einstellungen aus, und das Hinzufügen von --show-secrets gibt die privaten Schlüssel und Passwörter mit aus. Für eine Fehlersuche im Ticket braucht man die nicht. Berichten Sie stattdessen Typ, UUID, Zustand und die relevanten Routen und schwärzen Sie alles, was aus einem Geheimnisspeicher stammt.

Interaktive Aktivierung mit --ask ist der unterstützte Weg, eine fehlende Anmeldeinformation bereitzustellen, und unbeaufsichtigte Automatisierung braucht eine andere genehmigte Regelung statt eines gespeicherten Klartextpassworts.

Ein kurzer, geschwärzter Bericht ist leichter zu prüfen als ein vollständiger Auszug.

Ähnliche Artikel