Always On VPN ist kein LAN-Zugang: eine Ressourcen-Checkliste

Always On ist ein Verbindungslebenszyklus: Das Profil verbindet sich bei oder vor der Anmeldung und stellt die Verbindung ohne Zutun des Benutzers wieder her. Damit ist nicht gesagt, dass jedes private Ziel, jedes Protokoll und jeder Benutzer erlaubt ist. Die praktische Frage lautet, welche Ressourcen das eingesetzte Profil tatsächlich liefert, und diese Antwort verlangt eine Prüfung pro Ressource statt eines Blicks auf das Connected-Symbol.

Schritt 1: Die Ressource vor dem Test schriftlich festhalten

Beginnen Sie mit einem kurzen Eintrag pro Anwendung. Der Eintrag ist eine Planungsnotiz, kein Profil-XML, und die Werte müssen aus der realen Umgebung stammen: Name, Zielpräfix, Dienst und Port, Tunnelrolle, Identitätsgruppe und Resolver-Pfad.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

Der Eintrag erzwingt vier getrennte Fragen. Eine Route entscheidet, wohin die Adresse geht. Eine DNS-Richtlinie entscheidet, wie der Client die Adresse erfährt. Ein Verkehrsfilter entscheidet, ob dieser Verkehr die Verbindung nutzen darf. Firewall und Anwendungsberechtigungen des Ziels entscheiden, ob die Anfrage angenommen wird. Nichts davon folgt aus einem verbundenen Tunnel.

Schritt 2: Klären, welcher Tunnel die Ressource tragen soll

Windows Always On VPN kennt einen Gerätetunnel und einen Benutzertunnel, und beide werden als getrennte Profile mit getrennten Zertifikaten und getrennten Geltungsbereichen konfiguriert. Ein Gerätetunnel stellt üblicherweise nur die Infrastruktur bereit, die vor der Anmeldung nötig ist, etwa Verwaltung und Domänendienste. Der breite Anwendungszugang für Mitarbeiter gehört normalerweise zum Benutzertunnel.

Verkehrsfilter sind eine Funktion des Gerätetunnels, weshalb Microsofts Beispiel für den Gerätetunnel sie für Verwaltungsverkehr einsetzt. Kopiert man dieses Beispiel in ein allgemeines Profil für Ressourcenzugriff, entsteht ein Tunnel, der verbindet, aber den falschen Satz transportiert. Prüfen Sie mit Get-VpnConnection, welche Verbindung aktiv ist, und testen Sie die Ressource über diese Verbindung, nicht über die gerade zufällig bestehende.

Schritt 3: Die Route für die echte Adresse prüfen

Lösen Sie den Anwendungsnamen einmal auf und prüfen Sie dann die Route für diese Adresse: Find-NetRoute -RemoteIPAddress 10.20.5.10 meldet die gewählte Schnittstelle, den nächsten Hop und die Quelladresse. Ist die Schnittstelle der physische Adapter, liegt das Präfix nicht im Routensatz des Tunnels, oder der Client hat es per Split-Tunneling ausgeschlossen. Vergleichen Sie mit der Profildefinition, statt eine lokale Route davorzusetzen.

Ein lokales route add kann den Test bestehen lassen und beim nächsten Richtlinienabgleich verschwinden; deshalb gehört die Änderung in das verwaltete Profil. Prüfen Sie das Präfix in der Definition von Benutzer- und Geräteprofil und kontrollieren Sie die Split-Tunneling-Einstellung: Ein Full-Tunnel-Profil braucht keine Route pro Präfix, ein Split-Tunneling-Profil braucht eine für jedes private Präfix, das es tragen soll.

Schritt 4: Die Auflösung privater Namen getrennt testen

Private Namen sind ein eigener Richtlinienpfad. Das Profil kann NRPT-Regeln und eine DNS-Suffixsuchliste liefern, und diese Regeln gelten, solange der Tunnel verbunden ist. Lesen Sie mit Get-DnsClientNrptPolicy, was der Client tatsächlich erhalten hat, und testen Sie dann in derselben Sitzung einen Namen und eine Adresse. Namen, die scheitern, während Adressen funktionieren, deuten auf den Resolver-Pfad; scheitern beide, auf die Route.

Ein Name kann auch auf eine Adresse außlösen, die außerhalb der Tunnelrouten liegt, was eine verwirrende Mischung aus Erfolg und Zeitüberschreitung ergibt. Vergleichen Sie die zurückgegebene Adresse mit dem Präfix in Ihrem Eintrag. Weichen sie ab, antwortet die private Zone mit einer öffentlichen oder alternativen Adresse, und die passende Route ist nicht die geplante.

Schritt 5: Filter, Identität und die eigene Sperre der Anwendung prüfen

Verkehrsfilter begrenzen, welche Protokolle und Ports den Gerätetunnel nutzen dürfen, und ein leerer oder enger Filtersatz kann eine Ressource blockieren, die die Route sonst tragen würde. Auf der Identitätsseite ordnet das Profil die Verbindung einer Gruppe zu, und die Ressource hat ihre eigene Autorisierung. Wer sich verbinden kann, ist nicht automatisch jemand, den der Dateiserver akzeptiert.

Ändern Sie das verwaltete Profil über seinen Eigentümer, sei das Intune, eine ProfileXML-Bereitstellung oder ein Skript des Betriebsteams. Testen Sie danach nach einer normalen Wiederverbindung und nach einem Neustart, denn die geprüfte Fehlerart ist oft eine veraltete lokale Route oder ein Profil, das nur einmal angewendet wurde. Halten Sie die Profilversion neben dem Testergebnis fest; dieses Paar macht die nächste Änderung sicherer.