Warum ein beim Start gestarteter VPN-Dienst deinen Schlüsselbund nicht lesen kann
Ein VPN beim Systemstart hat keinen entsperrten Geheimnisagenten zum Ausleihen. Lies die Geheimnis-Flags der Verbindung, bevor du ein Passwort zurücksetzt, das der Server nie abgelehnt hat.
Eine Verbindung, die nach der Anmeldung funktioniert und davor scheitert, bedeutet meist, dass der Startversuch kein Geheimnis beschaffen konnte, nicht dass der Server eines abgelehnt hat. Die Anmeldeinformation existiert; der Kontext, der sie anfordert, nicht. Diese eine Unterscheidung erspart ein unnötiges Zurücksetzen des Passworts.
Folge der Anfrage: Etwas startet die Verbindung, bevor eine Desktop-Sitzung existiert, und der Geheimnisspeicher, der normalerweise antwortet, ist noch nicht entsperrt. Die beiden Kontexte sind sich uneinig, wem das Geheimnis gehört, und das Profil hält fest, welcher von ihnen es liefern soll.
Was der Startpfad tatsächlich anfordert
Beim Start läuft NetworkManager als Systemdienst ohne Benutzersitzung, ohne Sitzungs-D-Bus und ohne entsperrten Schlüsselbund. Ein Verbindungsprofil lässt sich trotzdem hochfahren, aber nur mit Geheimnissen, die der Dienst selbst erreichen kann. Alles, was einem Geheimnisagenten gehört, hängt, bis ein Mensch sich anmeldet und der Agent erscheint. Der Dienst tut genau das, was seine Konfiguration sagt; das Profil ist das, was sich ändern muss.
Der Fehler steht in der Verbindung, statt in einem Schlüsselbund verborgen zu sein.
Die Geheimnis-Flags einer Verbindung lesen
Frag die Verbindung, was sie erwartet, nicht was der Desktop sich merkt. Die Flag-Spalte beantwortet die Frage direkt, und sie übersteht Neustarts in der Profildatei auf der Festplatte.
Beginne mit der Profilliste und bestätige dann, welche Verbindung so eingestellt ist, dass sie von selbst hochkommt. Dann gib eine Verbindung aus und lies die Passwort-Flags:
nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show nmcli connection show "Work VPN" | grep -i -E "password|secret|key" journalctl -b -u NetworkManager --grep "secret"
Der erste Befehl bestätigt, welche Profile existieren und ob eines auf automatisches Verbinden gesetzt ist, wodurch ein unbeaufsichtigter Versuch überhaupt beginnt. Der zweite legt die Flag-Werte offen, und der dritte zeigt, wie der Dienst sich beschwert, dass kein Agent für ein bestimmtes Geheimnis geantwortet hat. Eine Logzeile, die ein Geheimnis als agent-eigen bezeichnet, ist die ganze Diagnose in einem Satz.
| Flag value | Where the secret lives | Behaviour before login |
|---|---|---|
| 0 | Stored in the connection profile | Available to the system service |
| 1 | Owned by a secret agent | Blocks until the agent is unlocked |
| 2 | Never stored | Prompts on every activation |
| 4 | Not required | Never requested at all |
Warum der Umzug der Verbindung in den Systembereich die Antwort ändert
Eine Verbindung, die einem Benutzer gehört, wird unter dem Agenten dieses Benutzers aktiviert, weshalb sie einwandfrei funktioniert, sobald der Desktop läuft. Der Umzug in den Systembereich entfernt den Agenten aus dem Pfad, sodass dasselbe Profil sich anders verhält, ohne dass eine einzige Zeile VPN-Konfiguration sich ändert.
Dieser Umzug ist ein legitimes Design und bringt eine Anforderung mit: Das Geheimnis muss für den Systemdienst erreichbar sein. Es im Profil zu speichern, es über eine Anmeldeinformation im Systembereich bereitzustellen oder eine interaktive Abfrage im richtigen Moment zu akzeptieren, sind alles gültige Antworten. Flag 1 stehen zu lassen und zu hoffen, nicht.
Ein privater Schlüssel mit eigener Passphrase fügt eine zweite Ebene hinzu. Selbst ein gespeichertes Kontopasswort entsperrt keinen Schlüssel, der eine Passphrase will, also prüfe, welches Geheimnis die scheiternde Stufe tatsächlich anfordert, bevor du etwas änderst.
Was du nicht tun solltest und was stattdessen
Jede Anmeldeinformationsdatei für alle lesbar zu machen oder die Authentifizierung abzuschalten, damit keine Abfrage nötig ist, tauscht eine Unannehmlichkeit beim Start gegen eine dauerhafte Offenlegung. Beides verbirgt auch die Abhängigkeit, statt sie zu lösen, und das nächste Image-Update bringt denselben Fehler zurück.
Nutze in dieser Stufe den Mechanismus, den deine Distribution für unbeaufsichtigte Aktivierung dokumentiert, und bestätige dann, dass die Flags des Profils dazu passen. Prüfe das Ergebnis von einem sauberen Start aus statt aus einer Shell, die bereits einen Agenten hat. Schreibe den Verbindungseigentümer, die Geheimnisquelle und die Stufe auf, die funktionieren muss, damit eine spätere Änderung des Autostarts nicht stillschweigend eine Abhängigkeit davon wieder einführt, dass jemand zuerst einen Desktop entsperrt. Dokumentation ist der Unterschied zwischen einem reparierten Dienst und einem, der im nächsten Quartal wieder bricht.
Teste von einem kontrollierten sauberen Start aus statt mit einem manuellen Neuversuch nach der Anmeldung. Der Neuversuch gelingt aus dem Grund, aus dem der Startversuch scheiterte, und genau diesen Beweis zerstört ein schneller Test.