Windows auf Arm: Lädt der VPN-Treiber tatsächlich?
Eine emulierte App kann starten, während ein VPN-Treiber im Kernelmodus nicht geladen werden kann. Prüfen Sie die Paketarchitektur und die erforderlichen Komponenten, bevor Sie einen Laptop migrieren.
Das Installationsprogramm läuft, das Fenster öffnet sich und die Anmeldeaufforderung erscheint, also wirkt die Migration abgeschlossen. Dann scheitert der Tunnel an der Stelle, an der der Client seinen virtuellen Adapter braucht, und der Fehler nennt einen Dienst oder Treiber statt Anmeldedaten. Unter Windows auf Arm ist diese Reihenfolge üblich, weil sich die Kompatibilitätsregel zwischen Benutzermodus-Code und Kernelmodus-Code ändert. Die Freigabe eines Laptops braucht die zweite Prüfung, nicht die erste.
Fragen Sie nach der Architektur des gesamten Pakets und prüfen Sie sie dann auf dem Gerät.
Der Teil, den die Emulation nicht abdeckt
Windows auf Arm kann x86- und x64-Anwendungen per Emulation ausführen, solange sie im Benutzermodus bleiben. Kernelmodus-Komponenten erhalten diese Behandlung nicht: Ein Treiber muss für Arm64 gebaut sein, um überhaupt geladen zu werden. Microsoft dokumentiert diese Grenze, und genau dort sitzen VPN-Clients meistens, weil viele von ihnen einen virtuellen Netzwerkadapter oder einen Filtertreiber installieren.
Ein Paket kann also eine funktionierende Oberfläche bieten und trotzdem unbrauchbar sein. Der Fehler zeigt sich als fehlender Adapter, als Dienst, der nicht startet, oder als Tunnel, der nie zustande kommt. An diesem Punkt sollte ein Pilot stoppen. Ein Anmeldebildschirm ist kein Beweis für einen funktionierenden Datenpfad.
Drei Bedingungen, die über die Migration entscheiden
Die erste ist das Paket. Ein x64-Build und ein Arm64-Build heißen beide 64-Bit und sind nicht austauschbar, daher beweist ein Download, der nur als Windows 64-Bit beschrieben wird, nichts über ein Arm-Gerät. Der vom Hersteller unterstützte Installer für diese Architektur ist der einzig akzeptable Ausgangspunkt.
Die zweite sind die übrigen erforderlichen Komponenten. Gerätezustandsprüfungen, browserbasierte Authentifizierungshilfen und Smartcard-Middleware können jeweils eigene Architekturanforderungen haben, und ein Erfolg nur des Tunnels zeigt nicht, dass die Zugriffsrichtlinie der Organisation erfüllt ist.
Die dritte ist das Gateway und seine unterstützte Client-Auswahl. Hat der freigegebene Client keinen Arm-Build, ist ein anderer Client nur dort akzeptabel, wo der Gateway-Betreiber das Protokoll dieses Clients, sein Authentifizierungsverfahren und sein Richtlinienverhalten unterstützt. Ein integriertes Windows-VPN-Profil kann einen proprietären Client nicht ersetzen, nur weil beide als IPsec bezeichnet werden.
Lesen Sie die Architektur auf dem Gerät
Bestätigen Sie, um welches Gerät es sich handelt, und sehen Sie dann nach, welche Treiber das Paket tatsächlich installiert hat. Die Auflistung dauert eine Minute und verhindert eine Diskussion darüber, was "64-Bit" bedeutet.
Get-CimInstance Win32_OperatingSystem | Select-Object OSArchitecture $env:PROCESSOR_ARCHITECTURE pnputil /enum-drivers | Select-String -Pattern 'vpn|tap|wintun' -Context 0,3 Get-NetAdapter | Format-Table Name,InterfaceDescription,DriverProvider
Zeigt die Adapterliste nichts für den Client, oder meldet der Treibereintrag eine Architekturabweichung, endet die Migration dort. Einen Arm64-Treiber in den alten Container zu legen, wird vom Hersteller nicht unterstützt, und Einstellungen für den Kompatibilitätsmodus wandeln keinen x64-Kerneltreiber um.
Vergleichen Sie die installierte Version mit der unterstützten Liste des Herstellers für Arm, und notieren Sie den Unterschied, falls der Installer aus einem internen Repository statt vom Hersteller stammt.
Geben Sie die Arbeitslast frei, nicht den Anmeldebildschirm
Führen Sie den Pilotbetrieb durch, während das zuvor funktionierende Gerät als Rückfalloption verfügbar bleibt. Prüfen Sie die Profilbereitstellung, die vorgesehene Identität und alle Geräteprüfungen, und testen Sie dann die private Anwendung statt nur den Tunnelstatus.
Beziehen Sie privates DNS, die erforderlichen Routen und Adressfamilien, die Wiederverbindung nach einem Netzwerkwechsel und den festgelegten getrennten Zustand ein. Halten Sie Client- und Komponentenversionen zusammen mit dem Ergebnis fest, weil das nächste Update dieselben Fragen erneut stellen wird.
Bestätigen Sie schließlich, dass es unterstützte Aktualisierungs- und Entfernungspfade für diese Plattform gibt. Ein Paket, das erst nach undokumentierten Ersetzungen funktioniert, erzeugt beim nächsten Release dasselbe Migrationsproblem, mit weniger Zeit zur Lösung.