ConnMan VPN: Das fehlende Menü ist ein Daemon, kein Protokoll

Die Annahme ist, dass ein ConnMan-System ohne VPN-Eintrag im Desktop keine VPN-Unterstützung installiert hat. Meist gibt es Unterstützung für WLAN und keine für den VPN-Daemon, die Anbieterkonfiguration oder den Authentifizierungsagenten, und das sind drei getrennte Abwesenheiten. Das Menü ist eine Ansicht auf diese Komponenten, nicht das Feature selbst. Version und Paketierung prüfen sagt Ihnen mit einem Befehl mehr als beliebig viele Desktop-Fehlerberichte.

Der Mythos: das Menü ist das VPN-Feature

Beginnen Sie mit der installierten ConnMan-Version und den Paketen, die mit ihr kamen. Ein Fehlerbericht aus einer älteren Veröffentlichung beschreibt einen anderen Funktionsumfang, und ihn zu zitieren endet meist damit, dass jemand einen Netzwerkmanager neu installiert, den er nicht hätte ersetzen müssen.

Schreiben Sie auf, was Sie tatsächlich haben, bevor Sie etwas ändern: die Daemon-Binärdatei, das Anbieterverzeichnis und ob ein Agent vorhanden ist.

Welcher Daemon den Tunnel besitzt

In der ConnMan-1.41-Dokumentation für Debian bookworm ist connman-vpnd der Daemon, der VPN-Verbindungen neben connmand verwaltet. Sie listet Integrationen für benannte VPN-Helfer auf, darunter OpenVPN und OpenConnect. Diese Liste ist eine Aussage über Helfer, kein Versprechen, dass jedes Protokoll oder jeder Authentifizierungsablauf funktioniert. Lesen Sie sie als Menü dessen, was zu prüfen ist, nicht als Kompatibilitätsgarantie.

Ordnen Sie dann die Integration dem freigegebenen Protokoll des Gateways zu. Das Wort Cisco sagt Ihnen nicht, ob Sie eine Verbindung im alten vpnc-Stil oder einen AnyConnect-kompatiblen Ablauf brauchen, und die falsche Wahl erzeugt einen Authentifizierungsfehler, der wie ein Problem mit den Anmeldedaten aussieht.

Wenn sowohl ein eigenständiger Helfer als auch ConnMan den Tunnel aufbauen können, legen Sie vor dem Start fest, wer Routen, DNS und Lebenszyklus besitzt.

Daemon-Einstellungen sind keine Anbieter-Einstellungen

Die allgemeine Konfiguration des Daemons und die Konfiguration eines einzelnen Anbieters sind verschiedene Dateien in verschiedenen Formaten. In der dokumentierten bookworm-Anordnung liest der Daemon /etc/connman/connman-vpn.conf, während Anbieter-Provisioning-Dateien unter /var/lib/connman-vpn/ mit der Endung .config liegen. Ein OpenVPN-Profil in dieses Verzeichnis zu legen macht es nicht zu einer ConnMan-Provisioning-Datei. Das versionsgebundene Anbieterhandbuch beschreibt die Anbieterabschnitte und die typspezifischen Felder, die diese Dateien tatsächlich brauchen.

Übersetzen Sie nur über die unterstützte Zuordnung der installierten Integration. Zertifikatsvertrauen, Verweise auf private Schlüssel, Gateway-Identität, Routen und Authentifizierungseingaben behalten jeweils ihre Rolle, und ein Beispiel für einen anderen Anbietertyp ist nicht austauschbar, nur weil beide eine Serveradresse brauchen.

Wenn ein Anbieter nicht lädt, vergleichen Sie seine Felder mit dem Handbuch für die installierte Veröffentlichung statt mit einem Blog-Beispiel.

Der Authentifizierungsagent ist eine eigene Abhängigkeit

Eine Anbieterdefinition kann trotzdem einen Agenten brauchen, um Anmeldedaten zu beschaffen oder einen Authentifizierungsaustausch abzuschließen. Für seine OpenConnect-Integration erklärt dasselbe Handbuch, dass fehlende authentifizierungsbezogene Werte über die VPN Agent API angefordert werden können und dass ein kurzlebiges Cookie in der Regel nicht als dauerhaftes Konfigurationsgeheimnis taugt. Dieser Mechanismus garantiert keine Unterstützung für jeden Browser-Login, jede MFA-Abfrage oder jede Gateway-Zustandsprüfung. Bestätigen Sie den gesamten Ablauf mit demjenigen, dem die Bereitstellung gehört.

Kompensieren Sie einen fehlenden Agenten nicht, indem Sie ein Passwort oder ein Sitzungstoken in eine breit lesbare Datei schreiben. Das macht aus einer fehlenden Integration eine Offenlegung von Anmeldedaten, und das zweite Problem überlebt das erste.

Wenn das Gateway einen interaktiven Login braucht, ist der Agent Teil des Entwurfs und keine optionale Zugabe.

Prüfen Sie vier Ergebnisse, nicht eines

Prüfen Sie nach der autorisierten Bereitstellung vier Dinge getrennt: der Anbieter ist ausgewählt, die Verbindung ist authentifiziert, die effektiven Routen sind die beabsichtigten, und der Resolver verhält sich wie erwartet. Ein laufender Daemon, ein gelisteter Anbieter und eine Anwendung, die ihre Ressource erreicht, sind drei verschiedene Ergebnisse, und nur das letzte ist das eigentliche Ziel des Nutzers. Sie getrennt zu protokollieren sagt Ihnen, welche Stufe zu reparieren ist.

Nehmen Sie das Wiederverbindungsverhalten und die erforderliche Richtlinie für den Nichtverfügbarkeitszustand in diese Prüfung auf, denn ein Tunnel, der einmal hochkommt und sich nie erholt, ist nicht ausgerollt. Halten Sie die funktionierende Basiskonfiguration des Netzwerks wiederherstellbar, während Sie die VPN-Integration ändern.

Den WLAN-Manager zu ersetzen, nur um einen Knopf zu bekommen, ist eine viel größere Änderung als der fehlende Vorgang, und meist gewinnt der Mythos.