Windows sur Arm : le pilote VPN se charge-t-il vraiment ?

L’installateur s’exécute, la fenêtre s’ouvre et l’invite de connexion apparaît, donc la migration semble terminée. Puis le tunnel échoue au moment où le client a besoin de son adaptateur virtuel, et l’erreur mentionne un service ou un pilote plutôt que des identifiants. Sous Windows sur Arm, cette séquence est courante, car la règle de compatibilité change entre le code en mode utilisateur et le code en mode noyau. Approuver un ordinateur portable exige la seconde vérification, pas la première.

Demandez l’architecture du paquet complet, puis vérifiez-la sur la machine.

La partie que l’émulation ne couvre pas

Windows sur Arm peut exécuter des applications x86 et x64 par émulation tant qu’elles restent en mode utilisateur. Les composants en mode noyau ne bénéficient pas de ce traitement : un pilote doit être compilé pour Arm64 pour se charger. Microsoft documente cette frontière, et c’est exactement là que se trouvent souvent les clients VPN, car beaucoup installent un adaptateur réseau virtuel ou un pilote de filtre.

Un paquet peut donc présenter une interface fonctionnelle et rester inutilisable. La défaillance apparaît sous la forme d’un adaptateur manquant, d’un service qui ne démarre pas ou d’un tunnel qui ne s’établit jamais. C’est le moment où une phase pilote doit s’arrêter. Un écran de connexion n’est pas la preuve d’un chemin de données fonctionnel.

Trois conditions qui décident de la migration

La première est le paquet. Une compilation x64 et une compilation Arm64 sont toutes deux dites 64 bits et ne sont pas interchangeables, donc un téléchargement décrit seulement comme Windows 64 bits ne prouve rien sur un appareil Arm. L’installateur pris en charge par le fournisseur pour cette architecture est le seul point de départ acceptable.

La deuxième est le reste des composants requis. Les contrôles de posture de l’appareil, les assistants d’authentification dans le navigateur et l’intergiciel de cartes à puce peuvent chacun avoir leur propre exigence d’architecture, et un succès du seul tunnel ne montre pas que la politique d’accès de l’organisation est satisfaite.

La troisième est la passerelle et son ensemble de clients pris en charge. Si le client approuvé n’a pas de compilation Arm, un autre client n’est acceptable que là où le propriétaire de la passerelle prend en charge le protocole de ce client, sa méthode d’authentification et le comportement de sa politique. Un profil VPN Windows intégré ne peut pas remplacer un client propriétaire simplement parce que les deux sont décrits comme IPsec.

Lisez l’architecture sur l’appareil

Confirmez de quelle machine il s’agit, puis regardez quels pilotes le paquet a réellement installés. L’énumération prend une minute et évite une discussion sur ce que signifie "64 bits".

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

Si la liste des adaptateurs ne montre rien pour le client, ou si l’entrée du pilote signale une incompatibilité d’architecture, la migration s’arrête là. Placer un pilote Arm64 dans l’ancien conteneur n’est pas quelque chose que le fournisseur prend en charge, et les paramètres du mode de compatibilité ne convertissent pas un pilote noyau x64.

Comparez la version installée avec la liste prise en charge par le fournisseur pour Arm, et notez la différence si l’installateur provient d’un dépôt interne plutôt que du fournisseur.

Approuvez la charge de travail, pas l’écran de connexion

Exécutez la phase pilote en gardant l’appareil fonctionnel précédent disponible comme solution de repli. Vérifiez le provisionnement du profil, l’identité prévue et les contrôles d’appareil éventuels, puis testez l’application privée plutôt que le seul état du tunnel.

Incluez le DNS privé, les routes et les familles d’adresses requises, la reconnexion après un changement de réseau et l’état déconnecté spécifié. Consignez les versions du client et des composants avec le résultat, car la prochaine mise à jour posera à nouveau les mêmes questions.

Enfin, confirmez qu’il existe des chemins de mise à jour et de suppression pris en charge pour cette plateforme. Un paquet qui ne fonctionne qu’après des substitutions non documentées crée le même problème de migration à la prochaine version, avec moins de temps pour le résoudre.