Cisco VPN se bloque après Hyper-V : délier ou reconstruire ?

Le client tourne à l'étape securing communications et n'affiche jamais d'invite de connexion, et la seule chose qui a changé est l'installation d'un émulateur. Ce schéma désigne l'adaptateur virtuel, pas le profil ni le mot de passe. La décision est de savoir si l'adaptateur est lié à un commutateur Hyper-V sur lequel il ne devrait pas être, ou s'il n'est jamais apparu.

Ces deux états se ressemblent dans le client et demandent des réparations différentes. L'un est une liaison que vous pouvez annuler ; l'autre est un problème de pilote que le déliement ne touchera pas.

Ce qu'attend l'étape securing communications

Avant que le tunnel soit construit, le client a besoin d'un chemin réseau local fonctionnel vers la passerelle. Il installe son propre adaptateur virtuel et l'utilise dans ce chemin. Si Hyper-V rattache cet adaptateur à un commutateur créé pour un émulateur, l'adaptateur peut cesser de fournir une route utilisable.

Le client n'indique pas quel adaptateur il attend. Le journal s'arrête généralement à la dernière étape atteinte, et la même panne apparaît pour chaque adresse de passerelle. C'est pourquoi l'historique d'installation compte plus que le texte de l'erreur. Le journal vaut quand même la peine d'être conservé ; il donne l'étape, pas la cause.

Ressaisir les identifiants ou réinstaller le profil ne peut pas changer une liaison de commutateur. Si ce sont vos deux premières actions, vous réparez la mauvaise couche.

Décision un : l'adaptateur VPN est-il lié au mauvais commutateur ?

Ouvrez Hyper-V Manager, puis Virtual Switch Manager, et lisez la liste des adaptateurs de chaque commutateur. L'adaptateur Cisco ne devrait pas apparaître comme un rattachement d'un commutateur d'émulateur. Si c'est le cas, c'est votre erreur, et la réparation consiste à le retirer de ce commutateur.

Redémarrez d'abord pour que le client démarre proprement plutôt qu'à moitié connecté. Retirez la liaison, appliquez-la, et laissez les autres adaptateurs tranquilles jusqu'à ce que vous ayez testé. Le changement est réversible et ne désinstalle rien, mais notez quels adaptateurs vous avez déliés.

Démarrez le client et essayez la connexion. S'il se bloque encore, déliez les autres adaptateurs virtuels un par un et testez après chacun, pour savoir lequel comptait.

Décision deux : l'adaptateur est-il actif mais sans adresse ?

Exécutez ipconfig /all depuis une invite élevée pour que les adaptateurs masqués soient inclus, et comparez la liste avec ce dont vous vous souvenez avant l'installation. Un adaptateur sans adresse et avec un état de support déconnecté signifie généralement que le pilote n'a pas démarré. Cela ne se répare pas en déliant. Notez l'état exact avant de changer quoi que ce soit.

Un adaptateur actif mais rattaché au mauvais commutateur est le cas de la section précédente. L'état de l'adresse est ce qui distingue les deux.

Restaurez l'émulateur sans restaurer la panne

Quand le tunnel fonctionne, rattachez l'adaptateur propre de l'émulateur à son commutateur et confirmez que la VM obtient une adresse. Ne rattachez pas l'adaptateur VPN. Testez à nouveau l'émulateur et le client avant de considérer que c'est terminé.

Sur un poste de travail géré, dites à l'administrateur quelle liaison vous avez modifiée. Une actualisation de stratégie ultérieure peut rétablir l'ancien rattachement, et le blocage reviendra sans cause évidente.

Notez le nom de l'adaptateur, le commutateur auquel il était lié et l'état de ipconfig avant et après. Si le blocage revient après une mise à jour, cette note est la différence entre une vérification de cinq minutes et un redémarrage à zéro.