Windows na Arm: czy sterownik VPN naprawdę się załaduje?

Instalator działa, okno się otwiera i pojawia się monit logowania, więc migracja wygląda na zakończoną. Potem tunel zawodzi w momencie, gdy klient potrzebuje swojego wirtualnego adaptera, a błąd wymienia usługę lub sterownik zamiast danych logowania. W Windows na Arm ta sekwencja jest typowa, ponieważ reguła zgodności zmienia się między kodem w trybie użytkownika a kodem w trybie jądra. Zatwierdzenie laptopa wymaga drugiego sprawdzenia, a nie pierwszego.

Zapytaj o architekturę całego pakietu, a następnie zweryfikuj ją na maszynie.

Część, której emulacja nie obejmuje

Windows na Arm może uruchamiać aplikacje x86 i x64 przez emulację, dopóki pozostają w trybie użytkownika. Składniki w trybie jądra nie dostają takiego traktowania: sterownik musi być zbudowany dla Arm64, aby w ogóle się załadował. Microsoft dokumentuje tę granicę i jest ona dokładnie tam, gdzie zwykle znajdują się klienci VPN, ponieważ wielu z nich instaluje wirtualny adapter sieciowy lub sterownik filtru.

Pakiet może więc pokazywać działający interfejs i nadal być bezużyteczny. Awaria objawia się jako brakujący adapter, usługa, która nie startuje, albo tunel, który nigdy nie powstaje. To jest punkt, w którym pilotaż powinien się zatrzymać. Ekran logowania nie jest dowodem działającej ścieżki danych.

Trzy warunki, które decydują o migracji

Pierwszy to pakiet. Kompilacja x64 i kompilacja Arm64 są obie nazywane 64-bitowymi i nie są wymienne, więc pobranie opisane tylko jako Windows 64-bit nie dowodzi niczego o urządzeniu Arm. Wspierany przez dostawcę instalator dla tej architektury jest jedynym akceptowalnym punktem wyjścia.

Drugi to pozostałe wymagane składniki. Kontrole stanu urządzenia, pomocniki uwierzytelniania w przeglądarce i oprogramowanie pośredniczące kart inteligentnych mogą mieć własne wymagania architektoniczne, a sukces tylko tunelu nie pokazuje, że polityka dostępu organizacji jest spełniona.

Trzeci to brama i obsługiwany przez nią zestaw klientów. Jeśli zatwierdzony klient nie ma kompilacji Arm, inny klient jest akceptowalny tylko tam, gdzie właściciel bramy obsługuje protokół tego klienta, jego metodę uwierzytelniania i zachowanie jego polityki. Wbudowany profil Windows VPN nie może zastąpić zastrzeżonego klienta tylko dlatego, że oba opisuje się jako IPsec.

Odczytaj architekturę na urządzeniu

Potwierdź, czym jest maszyna, a potem sprawdź, które sterowniki pakiet faktycznie zainstalował. Wyliczenie zajmuje minutę i zapobiega sporowi o to, co znaczy "64-bit".

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

Jeśli lista adapterów nie pokazuje nic dla klienta albo wpis sterownika zgłasza niezgodność architektury, migracja zatrzymuje się tam. Umieszczenie sterownika Arm64 w starym kontenerze nie jest czymś, co dostawca wspiera, a ustawienia trybu zgodności nie konwertują sterownika jądra x64.

Porównaj zainstalowaną wersję z obsługiwaną listą dostawcy dla Arm i zanotuj różnicę, jeśli instalator pochodzi z wewnętrznego repozytorium, a nie od dostawcy.

Zatwierdź obciążenie, a nie ekran logowania

Uruchom pilotaż, mając poprzednie działające urządzenie jako opcję awaryjną. Zweryfikuj przygotowanie profilu, zamierzoną tożsamość i wszystkie kontrole urządzenia, a następnie przetestuj aplikację prywatną, a nie tylko stan tunelu.

Uwzględnij prywatny DNS, wymagane trasy i rodziny adresów, ponowne połączenie po zmianie sieci i określony stan rozłączenia. Zapisuj wersje klienta i składników razem z wynikiem, ponieważ następna aktualizacja znowu zada te same pytania.

Na koniec potwierdź, że dla tej platformy istnieją obsługiwane ścieżki aktualizacji i usuwania. Pakiet, który działa dopiero po nieudokumentowanych zamianach, tworzy ten sam problem migracyjny przy następnym wydaniu, z mniej czasu na jego rozwiązanie.