Azure VPN Client : la plateforme VPN n'a pas déclenché la connexion

La ligne d'état indique que la plateforme VPN n'a pas déclenché la connexion, le profil s'importe sans erreur et la passerelle est saine pour tous les autres. Ce message décrit un transfert à l'intérieur de Windows, pas un identifiant refusé, donc l'ordre utile va du changement d'état le moins coûteux au plus destructeur. Réimporter un profil coûte une minute, réparer le paquet coûte un redémarrage et le réinitialiser coûte tous les profils de la machine. Travailler dans le mauvais ordre détruit les preuves nécessaires pour distinguer ces cas.

Réimporter, réparer, réinitialiser : trois coûts différents

Les trois actions ne sont pas interchangeables et une seule est réversible sans travail. Réimporter actualise le profil et conserve l'installation de l'application. Réparer conserve les profils importés et réécrit les fichiers du paquet. Réinitialiser supprime les profils avec l'état de l'application, vous réimportez donc tout ensuite.

Commencez par un téléchargement récent d'azurevpnconfig.xml dès que la passerelle, le pool d'adresses ou la méthode d'authentification ont changé. Un profil qui nomme une passerelle supprimée produit exactement cette ligne d'état, et aucune réparation côté client ne corrige un fichier qui pointe vers quelque chose qui n'existe plus.

Avant toute étape destructrice, vérifiez que l'application est autorisée à s'exécuter en arrière-plan : Paramètres, Applications, Applications installées, Azure VPN Client, Options avancées. Un client suspendu ne peut pas terminer le transfert de plateforme.

RasMan est le service auquel le client transfère

Le Remote Access Connection Manager transforme une demande du client en connexion Windows. Redémarrez-le depuis une invite élevée avec net stop rasman puis net start rasman, et reconnectez-vous avant de changer autre chose.

Si cela rétablit la connexion, définissez le type de démarrage pour que le correctif survive à un redémarrage : sc.exe config rasman start= delayed-auto. Un service qui tourne maintenant mais désactivé au démarrage reproduit la même panne demain matin.

Surveillez un service qui démarre puis s'arrête de lui-même. Ce schéma indique une dépendance ou une stratégie, et un redémarrage ne tiendra que quelques minutes, ce qui est pire qu'une panne nette car cela ressemble à un problème réseau intermittent. Vérifiez le journal System pour le nom du service autour de la tentative et confirmez que les dépendances tournent aussi.

Utilisateur actuel ou ordinateur local : deux magasins de certificats

Si le client s'ouvre avec une liste de certificats vide, la faute n'est ni au profil ni au service. Le client lit le magasin personnel de l'utilisateur actuel : ouvrez certmgr.msc, déployez Certificates, Current User, Personal, Certificates et confirmez que le certificat y est avec une clé privée.

Le magasin de l'ordinateur local ouvert avec certlm.msc est un autre magasin, et une installation là ne satisfait pas un client qui cherche dans le magasin utilisateur. Avec l'authentification par certificat, la passerelle ne détient que la clé publique de la racine, et chaque appareil a besoin de son propre certificat émis par cette racine. Un certificat copié d'une autre machine arrive généralement sans sa clé privée, ce qui produit une entrée sélectionnable qui ne peut toujours pas s'authentifier.

Un sélecteur vide est un problème de magasin, pas de tunnel.

Authentification par certificat ou Azure AD : des formes d'échec différentes

Pour l'authentification Azure AD, la configuration point à site exige l'URL du locataire, l'identifiant de l'application Azure VPN Client comme audience et l'émetteur STS, avec un administrateur accordant son consentement à l'application Azure VPN. Enregistrez cette configuration, retéléchargez le paquet et importez le nouveau fichier au lieu de réutiliser une copie ancienne.

Confirmez aussi que le pool d'adresses du client ne chevauche ni le réseau virtuel ni une plage locale, et que le groupe de sécurité réseau de la machine cible autorise ce pool. Ces deux erreurs survivent à toute réparation côté client.

Côté portable ou côté passerelle

Ne jugez pas le tunnel sur une vérification d'adresse publique. Une connexion point à site n'envoie pas tout le trafic internet vers Azure, donc une adresse publique inchangée est attendue quand le tunnel fonctionne correctement. Testez plutôt une adresse privée dans le réseau virtuel et lisez les itinéraires effectifs sur la machine.

Notez quelle étape a rétabli la connexion, la version du client, la date de téléchargement du profil et si un certificat ou le fournisseur d'identité a fourni l'identifiant. Cette trace transforme la prochaine occurrence en vérification de deux minutes et montre si les pannes dérivent vers la passerelle au lieu de rester sur le portable.

Ordre de travail : réimportez un profil à jour, redémarrez RasMan, autorisez l'exécution en arrière-plan, réparez le paquet et ne réinitialisez que si le magasin de certificats est confirmé intact.