Ein sekundäres VPN gehört zu einem Wi-Fi-Profil, nicht zu allen

Richten Sie ein VPN als sekundäre Verbindung des Heim-WLANs ein, und alles funktioniert, bis sich der Laptop mit einem anderen Zugangspunkt verbindet und der Tunnel unten bleibt. Die neue Verbindung ist ein separates Konfigurationsobjekt mit eigener UUID und hat keinen Grund, die Bindung zu kennen, die Sie für ihren Vorgänger erstellt haben. Nichts war defekt; die Verknüpfung existierte einfach nie.

Die Verbindungsreferenz von NetworkManager definiert sekundäre Verbindungen als UUIDs, die zusammen mit einer bestimmten Basisverbindung aktiviert werden. Sie merkt auch an, dass gewöhnliche VPN-Profile keine automatische Aktivierung implementieren, wie es Basisverbindungen tun. Beide Aussagen führen zum selben Schluss: Die Verknüpfung gilt pro Profil, und jemand muss sie für jedes neue anlegen.

Was ein sekundäres Element tatsächlich ist

Eine Basisverbindung hat eine Identität, eine UUID und eine Liste sekundärer Verbindungen. Bei ihrer Aktivierung aktiviert der Manager auch diese sekundären Verbindungen der Reihe nach, und so folgt ein VPN einem WLAN ohne manuellen Klick. Die Beziehung liegt auf der Basisverbindung und wird als UUID-Zeichenfolgen geschrieben, nicht als Namen. Diese Wahl der Darstellung ist kein Nebeneffekt; sie lässt die Verknüpfung ein Umbenennen überleben.

Dieses Detail mit den Namen ist wichtiger, als es aussieht. Das Umbenennen eines VPN-Profils lässt seine UUID unberührt, sodass bestehende Verknüpfungen weiter funktionieren. Das Löschen des alten Profils und das Importieren eines neuen erzeugt eine neue UUID, und jede Verknüpfung, die auf die alte zeigte, zeigt nun auf nichts.

Prüfen Sie die vorhandene Liste, bevor Sie etwas anhängen. Ein Heimprofil mit einer sekundären Verbindung ist keine Regel, die auf jedes SSID passt; es ist eine Zeile in einem Objekt und wird nicht herangezogen, wenn eine andere Basis aktiviert wird.

Setzen Sie die Verknüpfung dorthin, wo Profile erstellt werden

Machen Sie auf einem persönlichen Rechner das Anhängen der vorgesehenen sekundären Verbindung zu einem Teil des Hinzufügens jedes erlaubten WLAN-Profils. Das ist eine Gewohnheit statt einer Funktion, aber eine Gewohnheit, die einen konsistenten Zustand erzeugt, und sie kostet pro Netzwerk einen Befehl oder zwei Dialogbesuche. Führen Sie eine kurze Notiz darüber, welche Netzwerke den Tunnel tragen sollen, denn die Liste ist die Richtlinie.

Lassen Sie auf verwalteten Geräten den Bereitstellungsablauf den WLAN-Eintrag und seine VPN-Verknüpfung im selben Schritt erstellen, und wenden Sie dieselbe Behandlung auf erlaubte Profile an, die bereits existieren. Ein VPN-Profil allein zu verteilen lässt die Basisbeziehungen unspezifiziert, und so bekommt ein Gerätepark einen Tunnel, den nur die Hälfte der Laptops nutzt.

Wo Benutzer noch außerhalb des verwalteten Wegs Profile erstellen können, entscheiden Sie ausdrücklich, was mit diesen Einträgen geschieht. Anzunehmen, sie erbten eine Verknüpfung, ist keine Richtlinie; es ist eine Hoffnung mit angehängten Supportkosten.

Planen Sie den Wechsel der VPN-Identität ein

Die Bereitstellungsquelle braucht die UUID des vorgesehenen VPN, nicht einen Anzeigenamen, den jemand geraten hat. Wenn die Wartung dieses VPN durch ein frisch importiertes Objekt ersetzt, aktualisieren Sie die Bereitstellungsvorlage und die betroffenen bestehenden Verknüpfungen im selben Änderungsschritt. Ein Umbenennen ist kein Ersetzen, und beide als gleichwertig zu behandeln ist der Weg, auf dem ein funktionierender Rollout eine Woche später bricht.

Bewahren Sie die UUID neben dem Grund auf, warum sie existiert. Ein künftiger Ingenieur, der eine nackte UUID in einer Liste sekundärer Verbindungen findet, kann nicht sagen, ob sie aktuell ist, und wird sie beim Aufräumen wahrscheinlich löschen.

Aktivierung ist keine Durchsetzung

Eine Anforderung für eine sekundäre Verbindung erfolgt zum Aktivierungszeitpunkt. Sie blockiert Anwendungen nicht in der Zeitspanne, bevor die Authentifizierung abgeschlossen ist, und sie stoppt den Datenverkehr nicht, nachdem der Tunnel ausgefallen ist. Das sind verschiedene Eigenschaften, die von verschiedenen Mechanismen bereitgestellt werden, und ihre Vermischung erzeugt ein Design, das im Profil streng aussieht und in der Praxis nachgiebig ist.

Das Blockieren direkten Datenverkehrs ist eine eigene Funktion mit eigener Konfiguration und eigenen Fehlermodi, und sie muss den Datenverkehr berücksichtigen, der das Netzwerk erreichen muss, bevor irgendein Tunnel existieren kann: Captive Portals, Anmeldeseiten, der Endpunkt selbst. Eine Sperrrichtlinie, die vor der Authentifizierung nicht erfüllt werden kann, sperrt die Maschine aus genau dem Netzwerk aus, das sie braucht.

Bringen Sie diese Unterscheidung in die Anleitungen, die Benutzer tatsächlich lesen. Ein neues WLAN kann den Tunnel anfordern; die Durchsetzung entscheidet, ob etwas hinausgehen darf, wenn keine Verbindung möglich ist. Benutzer, denen nur die erste Hälfte erzählt wird, melden das Design als defekt.

Testen Sie mit einem wirklich neuen Profil

Verwenden Sie ein freigegebenes Testnetzwerk und ein neu erstelltes Basisprofil, nicht den Heimeintrag, der bereits funktioniert. Beobachten Sie die Basisaktivierung, die angeforderte sekundäre UUID und jede Authentifizierungsaufforderung der Reihe nach und notieren Sie, welche Stufe hängt, wenn sie hängt. Ein geheimer Agent, der nach der Desktop-Anmeldung verfügbar wird, ist nicht in jedem Startkontext automatisch vorhanden, deshalb gehört ein Neustart in den Testplan. Prüfen Sie dann die vorgesehene Ressource und den Fehlerpfad: Steht der Tunnel, bevor die Anwendung ihn braucht, und was passiert mit dieser Anwendung, wenn die Authentifizierung fehlschlägt?

Prüfen Sie dann die vorgesehene Ressource und den Fehlerpfad: Steht der Tunnel, bevor die Anwendung ihn braucht, und was passiert mit dieser Anwendung, wenn der Tunnel sich nicht authentifizieren kann? Diese beiden Beobachtungen sind die Abnahmekriterien, und keine von ihnen ist im Profil selbst sichtbar.