Warum Always On VPN im Firmennetz nicht mehr auslöst

Der Laptop tritt dem WLAN des Büros bei, und das Always On-Profil, das von zu Hause aus verbunden war, bleibt unten. Nichts im Ereignisprotokoll nennt das einen Fehler, denn aus Sicht des Clients ist das Netz vertrauenswürdig und der Tunnel unnötig. Die Erkennung vertrauenswürdiger Netze ist die Funktion, die diese Entscheidung trifft, und sie vergleicht bestimmte Werte, statt eine vertraute SSID zu erkennen. Wenn die Entscheidung falsch ist, müssen Sie sehen, welcher Vergleich bestanden wurde.

Was der Trigger tatsächlich vergleicht

Drei Dinge müssen zusammenpassen, bevor der Client ein Netz als vertrauenswürdig behandelt. Erstens muss das verbindungsspezifische DNS-Suffix, das Windows für den physischen Adapter erfasst, in der Suffixliste des Profils stehen. Zweitens muss das Verbindungsprofil, das Windows für dieses Netz führt, das von der Richtlinie erwartete sein, denn der Abgleich erfolgt gegen dieses Profil und nicht gegen einen Namen, den ein Benutzer in einen Drahtlosdialog getippt hat. Drittens muss das Netz so klassifiziert sein, wie es die Richtlinie verlangt, was praktisch ein Domänen- oder privates Netz bedeutet oder ein Gerät, dessen Richtlinie über die Verwaltung kam. Lassen Sie eines davon weg, und der Trigger greift.

Das ist ein engerer Test als der Vergleich der öffentlichen Ausgangsadresse des VPN und viel enger als das Vertrauen auf eine SSID. Ein Access Point, der den Firmennamen wiederholt, erfüllt die Suffix- und Profilvergleiche nicht aus eigener Kraft. Es bedeutet auch, dass die Funktion nichts darüber sagt, ob ein Netz sicher ist; sie sagt, ob dieses Gerät glaubt, bereits zu Hause zu sein.

Lesen Sie den aktuellen Zustand, bevor Sie das Profil ändern

Beginnen Sie mit dem, was Windows derzeit annimmt. Das Cmdlet für Verbindungsprofile meldet den Netzwerknamen, die Schnittstelle und die von Windows zugewiesene Kategorie, also den dritten Vergleich oben. Lesen Sie dann das VPN-Profil und suchen Sie die Liste der vertrauenswürdigen Suffixe, und zwar mit einem vollständigen Eigenschafts-Dump statt mit geratenen Eigenschaftsnamen:

Get-NetConnectionProfile
Get-VpnConnection -Name "Corp VPN" | Format-List *

Wenn dieser Dump das vertrauenswürdige Suffix in Ihrem Build nicht zeigt, greifen Sie auf die Profil-XML zurück, die die maßgebliche Kopie ist, wenn sich die Eigenschaftsoberfläche zwischen Versionen unterscheidet. Lesen Sie die XML aus der Verwaltungsrichtlinie oder aus dem Profilspeicher für alle Benutzer und vergleichen Sie ihre Suffixeinträge mit dem oben gemeldeten Adapter-Suffix. Notieren Sie beide Werte, bevor Sie einen davon anfassen.

Testen Sie die Grenze in beide Richtungen

Testen Sie am vorgesehenen Unternehmensanschluss und in einem weiteren freigegebenen Netz und notieren Sie, ob der Tunnel hochkam. Testen Sie dann dasselbe Gerät nach dem Verlassen. Ein Laptop, der zu Hause auslöst und im Büro unterdrückt, verhält sich wie entworfen, während eines, das nirgends auslöst, einen anderen Fehler hat. Prüfen Sie, ob die Ressourcen hinter dem Tunnel im ausgelösten Fall erreichbar sind, denn ein gestarteter Tunnel ist kein Beweis für einen funktionierenden Pfad.

Fügen Sie kein breites Suffix hinzu, nur damit eine Benachrichtigung verschwindet. Ein Suffix, das in vielen Netzen auftaucht, lehrt den Client, den Tunnel fast überall zu unterdrücken, und der folgende Supportaufwand ist schlimmer als die Benachrichtigung. Ändern Sie die Kriterien über den Profileigentümer, der in einer verwalteten Flotte der MDM-Administrator ist und nicht die Person am Laptop.

Halten Sie beide Testnetze zusammen mit dem Ergebnis im Protokoll fest. Eine Grenze, die nie getestet wurde, ist nur eine Behauptung.

Trennen Sie Unterdrückung von Blockierung

Ein Tunnel, der nicht gestartet wurde, ist keine blockierte Verbindung. Die Erkennung vertrauenswürdiger Netze steuert die automatische Auslösung, während Verkehrsfilterung und Kill-Switch-Verhalten separate Richtlinieneinstellungen mit eigenen Fehlermodi sind. Ein Gerät in einem vertrauenswürdigen Netz darf Verkehr legitimerweise außerhalb des Tunnels senden, und das ohne Lesen der Richtlinie ein Leck zu nennen, verwechselt zwei Entwürfe. Prüfen Sie die Verkehrsregeln des Profils, bevor Sie die Erkennung für ein Leck verantwortlich machen.

Dieselbe Unterscheidung erklärt die umgekehrte Beschwerde. Benutzer, die melden, das VPN habe zufällig gestoppt, beschreiben meist eine Netzänderung, die die Kriterien erfüllte, keinen Dienstausfall. Das passende Suffix und die Netzwerkkategorie sind die zu sammelnden Belege, und beide erscheinen in der Ausgabe oben.

Sammeln Sie diese Belege, bevor Sie die Richtlinie ändern. Ein Schalter, der das Symptom verbirgt, verbirgt auch die Ursache.

Halten Sie fest, worauf die Entscheidung beruhte

Schreiben Sie das passende Suffix, den Namen des Verbindungsprofils und die Netzwerkkategorie in die Bereitstellungsnotizen für jeden Standort. Wenn der Tunnel nicht hochkommt, verwandelt dieser Eintrag ein Rätsel in einen Vergleich: Entweder hat sich einer der drei Werte geändert oder die Richtlinie. Er gibt dem nächsten Ingenieur auch eine Möglichkeit, das Design zu bestätigen, statt die Erkennung abzuschalten, um das Ticket zu schließen.

Überprüfen Sie die Suffixliste, wenn ein Standort umbenannt oder eine Domäne konsolidiert wird, denn ein veralteter Eintrag unterdrückt den Tunnel weiter still. Die Referenz von Microsoft zur Erkennung vertrauenswürdiger Netze listet die Profilelemente und die Bereitstellungsvoraussetzungen auf, und sie ist das Dokument, das man zitiert, wenn jemand vorschlägt, die Liste zu erweitern.