Cisco VPN hängt nach Hyper-V: Bindung lösen oder neu aufbauen?

Der Client dreht bei securing communications und zeigt nie eine Anmeldeaufforderung, und das Einzige, was sich geändert hat, war eine Emulator-Installation. Dieses Muster deutet auf den virtuellen Adapter hin, nicht auf das Profil oder das Kennwort. Die Entscheidung ist, ob der Adapter an einen Hyper-V-Switch gebunden ist, an den er nicht gehört, oder ob er gar nicht hochkam.

Beide Zustände sehen im Client gleich aus und erfordern unterschiedliche Reparaturen. Der eine ist eine Bindung, die Sie rückgängig machen können; der andere ist ein Treiberproblem, das das Lösen der Bindung nicht berührt.

Worauf die securing-communications-Phase wartet

Bevor der Tunnel aufgebaut wird, braucht der Client einen funktionierenden lokalen Netzwerkpfad zum Gateway. Er installiert einen eigenen virtuellen Adapter und nutzt ihn als Teil dieses Pfads. Wenn Hyper-V diesen Adapter an einen Switch anhängt, der für einen Emulator angelegt wurde, kann der Adapter aufhören, eine brauchbare Route bereitzustellen.

Der Client meldet nicht, auf welchen Adapter er wartet. Das Protokoll endet meist bei der letzten erreichten Phase, und derselbe Fehler erscheint für jede Gateway-Adresse. Deshalb ist die Installationshistorie wichtiger als der Fehlertext. Das Protokoll lohnt sich trotzdem; es nennt die Phase, nicht die Ursache.

Anmeldedaten erneut eingeben oder das Profil neu installieren kann eine Switch-Bindung nicht ändern. Wenn das Ihre ersten beiden Schritte sind, reparieren Sie die falsche Ebene.

Entscheidung eins: Ist der VPN-Adapter an den falschen Switch gebunden?

Öffnen Sie den Hyper-V-Manager, dann den Virtual Switch Manager, und lesen Sie die Adapterliste für jeden Switch. Der Cisco-Adapter sollte nicht als Anhang eines Emulator-Switches erscheinen. Ist er es, ist das Ihr Fehler, und die Reparatur besteht darin, ihn von diesem Switch zu entfernen.

Starten Sie zuerst neu, damit der Client sauber und nicht halb verbunden startet. Entfernen Sie die Bindung, wenden Sie sie an, und lassen Sie die anderen Adapter in Ruhe, bis Sie getestet haben. Die Änderung ist umkehrbar und deinstalliert nichts, aber notieren Sie, welche Adapter Sie entbunden haben.

Starten Sie den Client und versuchen Sie die Verbindung. Hängt er weiterhin, lösen Sie die Bindungen der übrigen virtuellen Adapter einzeln und testen nach jedem, damit Sie wissen, welcher entscheidend war.

Entscheidung zwei: Ist der Adapter aktiv, aber ohne Adresse?

Führen Sie ipconfig /all in einer erhöhten Eingabeaufforderung aus, damit verborgene Adapter enthalten sind, und vergleichen Sie die Liste mit dem, was Sie von vor der Installation kennen. Ein Adapter ohne Adresse und mit getrenntem Medium bedeutet meist, dass der Treiber nicht gestartet ist. Das wird durch Entbinden nicht repariert. Notieren Sie den genauen Zustand, bevor Sie etwas ändern.

Ein Adapter, der aktiv, aber an den falschen Switch angebunden ist, ist der Fall aus dem vorigen Abschnitt. Der Adresszustand ist es, woran Sie die beiden unterscheiden.

Stellen Sie den Emulator wieder her, ohne den Fehler wiederherzustellen

Wenn der Tunnel läuft, hängen Sie den eigenen Adapter des Emulators wieder an seinen Switch und bestätigen Sie, dass die VM eine Adresse bekommt. Hängen Sie den VPN-Adapter nicht wieder an. Testen Sie Emulator und Client noch einmal, bevor Sie es als erledigt betrachten.

Auf einer verwalteten Workstation sagen Sie dem Administrator, welche Bindung Sie geändert haben. Eine spätere Richtlinienaktualisierung kann die alte Anbindung wiederherstellen, und der Hänger kehrt ohne erkennbare Ursache zurück.

Notieren Sie Adaptername, den Switch, an den er gebunden war, und den ipconfig-Zustand vorher und nachher. Kommt der Hänger nach einem Update zurück, ist diese Notiz der Unterschied zwischen einer Prüfung in fünf Minuten und einem Neuanfang.