Windows på Arm: vil VPN-driveren faktisk indlæses?

Installationsprogrammet kører, vinduet åbnes, og loginopfordringen vises, så migreringen ser færdig ud. Derefter fejler tunnelen på det punkt, hvor klienten har brug for sin virtuelle adapter, og fejlen nævner en tjeneste eller driver i stedet for legitimationsoplysninger. På Windows på Arm er denne rækkefølge almindelig, fordi kompatibilitetsreglen ændrer sig mellem kode i brugertilstand og kode i kernetilstand. Godkendelse af en laptop kræver den anden kontrol, ikke den første.

Spørg efter arkitekturen for hele pakken, og kontrollér den derefter på maskinen.

Den del, som emulering ikke dækker

Windows på Arm kan køre x86- og x64-programmer via emulering, så længe de bliver i brugertilstand. Komponenter i kernetilstand får ikke den behandling: en driver skal være bygget til Arm64 for at blive indlæst overhovedet. Microsoft dokumenterer grænsen, og det er præcis der, VPN-klienter typisk ligger, fordi mange af dem installerer en virtuel netværksadapter eller en filterdriver.

Så en pakke kan vise en fungerende grænseflade og alligevel være ubrugelig. Fejlen viser sig som en manglende adapter, en tjeneste, der ikke starter, eller en tunnel, der aldrig oprettes. Det er det punkt, hvor en pilot skal stoppe. En loginskærm er ikke bevis på en fungerende datasti.

Tre betingelser, der afgør migreringen

Den første er pakken. Et x64-build og et Arm64-build kaldes begge 64-bit og kan ikke udskiftes, så en download, der kun beskrives som Windows 64-bit, beviser intet om en Arm-enhed. Leverandørens understøttede installationsprogram til den arkitektur er det eneste acceptable udgangspunkt.

Den anden er resten af de krævede komponenter. Kontrol af enhedens tilstand, browserbaserede godkendelseshjælpere og middleware til smartkort kan hver især have deres eget arkitekturkrav, og en succes kun for tunnelen viser ikke, at organisationens adgangspolitik er opfyldt.

Den tredje er gatewayen og dens understøttede klientgruppe. Hvis den godkendte klient ikke har et Arm-build, er en anden klient kun acceptabel, hvor gatewayens ejer understøtter den klients protokol, dens godkendelsesmetode og dens politikadfærd. En indbygget Windows VPN-profil kan ikke erstatte en proprietær klient, blot fordi begge beskrives som IPsec.

Læs arkitekturen på enheden

Bekræft, hvad maskinen er, og se derefter, hvilke drivere pakken faktisk installerede. Oplistningen tager et minut og forhindrer en diskussion om, hvad "64-bit" betyder.

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

Hvis adapterlisten ikke viser noget for klienten, eller driverposten rapporterer en arkitekturkonflikt, stopper migreringen der. Det er ikke noget, leverandøren understøtter, at lægge en Arm64-driver i den gamle container, og indstillinger for kompatibilitetstilstand konverterer ikke en x64-kernedriver.

Sammenlign den installerede version med leverandørens understøttede liste til Arm, og notér forskellen, hvis installationsprogrammet kom fra et internt lager i stedet for fra leverandøren.

Godkend arbejdsbelastningen, ikke loginskærmen

Kør piloten med den tidligere fungerende enhed tilgængelig som fallback. Kontrollér klargøring af profilen, den tilsigtede identitet og eventuelle enhedskontroller, og afprøv derefter det private program i stedet for kun tunnelstatus.

Medtag privat DNS, de nødvendige ruter og adressefamilier, genopkobling efter en netværksændring og den angivne afbrudte tilstand. Registrér klient- og komponentversioner sammen med resultatet, fordi den næste opdatering vil stille de samme spørgsmål igen.

Bekræft endelig, at der findes understøttede opdaterings- og fjernelsesveje til denne platform. En pakke, der kun virker efter udokumenterede udskiftninger, skaber det samme migrationsproblem ved næste udgivelse, med mindre tid til at løse det.