Windows sur Arm: ĉu la VPN-ŝoforo vere ŝargiĝos?

La instalilo ruliĝas, la fenestro malfermiĝas kaj la salutpeto aperas, do la migrado ŝajnas finita. Poste la tunelo malsukcesas ĉe la punkto, kie la kliento bezonas sian virtualan adaptilon, kaj la eraro mencias servon aŭ ŝoforon anstataŭ akreditaĵojn. Sur Windows sur Arm tiu sinsekvo oftas, ĉar la kompatigebla regulo ŝanĝiĝas inter kodoj en uzantreĝimo kaj kodoj en kernreĝimo. Aprobi tekkomputilon bezonas la duan kontrolon, ne la unuan.

Demandu la arkitekturon de la tuta pako, poste kontrolu ĝin sur la maŝino.

La parto, kiun emulado ne kovras

Windows sur Arm povas ruli aplikaĵojn x86 kaj x64 per emulado dum ili restas en uzantreĝimo. Komponentoj en kernreĝimo ne ricevas tiun traktadon: ŝoforo devas esti konstruita por Arm64 por entute ŝargiĝi. Microsoft dokumentas tiun limon, kaj ĝi estas ĝuste tie, kie VPN-klientoj kutime troviĝas, ĉar multaj el ili instalas virtualan retadaptilon aŭ filtran ŝoforon.

Do pako povas prezenti funkciantan interfacon kaj tamen esti neuzebla. La malsukceso aperas kiel mankanta adaptilo, servo, kiu ne ekfunkcias, aŭ tunelo, kiu neniam establiĝas. Tio estas la punkto, ĉe kiu provo devus halti. Salutekrano ne estas pruvo de funkcianta datenvojo.

Tri kondiĉoj, kiuj decidas la migradon

La unua estas la pako. x64-konstruaĵo kaj Arm64-konstruaĵo ambaŭ nomiĝas 64-bitaj kaj ne estas interŝanĝeblaj, do elŝuto priskribita nur kiel Windows 64-bita pruvas nenion pri Arm-aparato. La subtenata instalilo de la vendanto por tiu arkitekturo estas la sola akceptebla komenca punkto.

La dua estas la ceteraj postulataj komponentoj. Kontroloj de aparatstato, retumilaj aŭtentigaj helpiloj kaj meza programaro por saĝaj kartoj povas ĉiu havi sian propran arkitekturan postulon, kaj sukceso nur de la tunelo ne montras, ke la alirpolitiko de la organizo estas plenumita.

La tria estas la enirejo kaj ĝia subtenata klientaro. Se la aprobita kliento ne havas Arm-konstruaĵon, alia kliento akcepteblas nur tie, kie la posedanto de la enirejo subtenas la protokolon de tiu kliento, ĝian aŭtentigan metodon kaj ĝian politikan konduton. Enkonstruita Windows VPN-profilo ne povas anstataŭi proprietan klienton nur ĉar ambaŭ priskribiĝas kiel IPsec.

Legu la arkitekturon sur la aparato

Konfirmu, kio estas la maŝino, poste rigardu, kiujn ŝoforojn la pako efektive instalis. Kalkulado daŭras minuton kaj malhelpas diskuton pri tio, kion signifas "64-bita".

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

Se la adaptila listo montras nenion por la kliento, aŭ la ŝofora ero raportas arkitekturan malkongruon, la migrado haltas tie. Enmeti Arm64-ŝoforon en la malnovan ujon ne estas io, kion la vendanto subtenas, kaj agordoj de kompatiga reĝimo ne konvertas kernan ŝoforon x64.

Komparu la instalitan version kun la subtenata listo de la vendanto por Arm, kaj notu la diferencon se la instalilo venis el interna deponejo anstataŭ de la vendanto.

Aprobu la laborŝarĝon, ne la salutekranon

Rulu la provon kun la antaŭe funkcianta aparato havebla kiel rezervaĵo. Kontrolu profilprovizadon, la celitan identecon kaj ajnajn aparatkontrolojn, poste provu la privatan aplikaĵon anstataŭ nur la tunelstaton.

Inkluzivu privatan DNS, la postulatajn itinerojn kaj adresfamiliojn, rekonekton post retŝanĝo kaj la difinitan malkonektitan staton. Notu klientajn kaj komponentajn versiojn kune kun la rezulto, ĉar la sekva ĝisdatigo denove demandos la samajn demandojn.

Fine, konfirmu, ke ekzistas subtenataj ĝisdatigaj kaj forigaj vojoj por ĉi tiu platformo. Pako, kiu funkcias nur post nedokumentitaj anstataŭoj, kreas la saman migran problemon ĉe la sekva eldono, kun malpli da tempo por solvi ĝin.