Windows på Arm: laddas VPN-drivrutinen verkligen?

Installationsprogrammet körs, fönstret öppnas och inloggningsprompten visas, så migreringen verkar klar. Sedan misslyckas tunneln vid den punkt där klienten behöver sin virtuella adapter, och felet nämner en tjänst eller drivrutin i stället för inloggningsuppgifter. På Windows på Arm är den här ordningen vanlig, eftersom kompatibilitetsregeln ändras mellan kod i användarläge och kod i kernelläge. Godkännande av en bärbar dator kräver den andra kontrollen, inte den första.

Fråga efter arkitekturen för hela paketet och verifiera den sedan på maskinen.

Delen som emulering inte täcker

Windows på Arm kan köra x86- och x64-program via emulering så länge de stannar i användarläge. Komponenter i kernelläge får inte den behandlingen: en drivrutin måste vara byggd för Arm64 för att kunna laddas alls. Microsoft dokumenterar den gränsen, och det är precis där VPN-klienter brukar ligga, eftersom många av dem installerar en virtuell nätverksadapter eller en filterdrivrutin.

Så ett paket kan visa ett fungerande gränssnitt och ändå vara oanvändbart. Felet visar sig som en saknad adapter, en tjänst som inte startar eller en tunnel som aldrig upprättas. Det är punkten där en pilot bör stoppa. En inloggningsskärm är inte bevis på en fungerande dataväg.

Tre villkor som avgör migreringen

Det första är paketet. En x64-build och en Arm64-build kallas båda 64-bitars och kan inte bytas ut, så en nedladdning som bara beskrivs som Windows 64-bitars bevisar ingenting om en Arm-enhet. Leverantörens installer som stöds för den arkitekturen är den enda acceptabla utgångspunkten.

Det andra är resten av de nödvändiga komponenterna. Kontroller av enhetens tillstånd, webbläsarbaserade autentiseringshjälpare och mellanprogramvara för smartkort kan ha var sitt arkitekturkrav, och en framgång bara för tunneln visar inte att organisationens åtkomstpolicy är uppfylld.

Det tredje är gatewayen och dess uppsättning klienter som stöds. Om den godkända klienten inte har någon Arm-build är en annan klient bara acceptabel där gatewayens ägare stöder den klientens protokoll, dess autentiseringsmetod och dess policybeteende. En inbyggd Windows VPN-profil kan inte ersätta en proprietär klient bara för att båda beskrivs som IPsec.

Läs arkitekturen på enheten

Bekräfta vad maskinen är och titta sedan på vilka drivrutiner paketet faktiskt installerade. Uppräkningen tar en minut och förhindrar en diskussion om vad "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

Om adapterlistan inte visar något för klienten, eller drivrutinsposten rapporterar en arkitekturkonflikt, stoppar migreringen där. Att lägga en Arm64-drivrutin i den gamla containern är inget som leverantören stöder, och inställningar för kompatibilitetsläge konverterar inte en x64-kerneldrivrutin.

Jämför den installerade versionen med leverantörens lista som stöds för Arm, och notera skillnaden om installationsprogrammet kom från ett internt arkiv i stället för från leverantören.

Godkänn arbetsbelastningen, inte inloggningsskärmen

Kör piloten med den tidigare fungerande enheten tillgänglig som reserv. Verifiera profilklargörandet, den avsedda identiteten och eventuella enhetskontroller, och testa sedan det privata programmet i stället för bara tunnelstatusen.

Inkludera privat DNS, de nödvändiga rutterna och adressfamiljerna, återanslutning efter en nätverksändring och det angivna frånkopplade tillståndet. Registrera klient- och komponentversioner tillsammans med resultatet, eftersom nästa uppdatering kommer att ställa samma frågor igen.

Slutligen, bekräfta att det finns uppdaterings- och borttagningsvägar som stöds för den här plattformen. Ett paket som bara fungerar efter odokumenterade utbyten skapar samma migreringsproblem vid nästa utgåva, med mindre tid att lösa det.