Hyper-V 之后 Cisco VPN 卡住：解绑还是重建

客户端在 securing communications 阶段一直转圈，从不出现登录提示，而唯一的变化是装了一个模拟器。这个现象指向虚拟适配器，而不是配置文件或密码。需要判断的是：适配器被绑定到了不该在的 Hyper-V 虚拟交换机上，还是它根本没有起来。

这两种状态在客户端里看起来一样，修法却不同。一种是你可以撤销的绑定；另一种是解绑根本碰不到的驱动问题。

securing communications 阶段在等什么

在隧道建立之前，客户端需要一条能通到网关的本地网络路径。它会安装自己的虚拟适配器，并把它作为这条路径的一部分。如果 Hyper-V 把这个适配器接到了为模拟器创建的交换机上，适配器就可能不再提供可用的路由。

客户端不会报告它在等哪个适配器。日志通常停在它到达的最后一个阶段，而且同样的失败会出现在每一个网关地址上。所以安装历史比错误文本更重要。日志仍然值得保留；它告诉你阶段，而不是原因。

重新输入凭据或重装配置文件都改不了交换机绑定。如果这是你的头两步，你修的是错误的层。

判断一：VPN 适配器是否绑到了错误的交换机

打开 Hyper-V 管理器，再打开虚拟交换机管理器，逐个查看每个交换机的适配器列表。Cisco 适配器不应该作为某个模拟器交换机的连接出现。如果出现了，那是你的问题，修法就是把它从那个交换机上移除。

先重启，让客户端干净地启动，而不是半连接状态。移除绑定、应用，然后在测试之前不要动其他适配器。这个改动可以回退，也不会卸载任何东西，但要记下你解绑了哪些适配器。

启动客户端并尝试连接。如果仍然卡住，就逐个解绑剩下的虚拟适配器，每解绑一个就测试一次，这样才知道是哪一个起了作用。

判断二：适配器是起来了但没有地址

在提升权限的命令提示符里运行 ipconfig /all，这样隐藏的适配器也会被列出，然后把你记得的安装前列表和它对比。没有地址、媒体已断开状态的适配器通常意味着驱动没有启动。这种情况解绑修不好。在改动任何东西之前先记下确切状态。

适配器起来了却接在错误的交换机上，就是上一节说的情况。地址状态正是区分两者的依据。

恢复模拟器，但不要恢复故障

隧道能通之后，把模拟器自己的适配器重新接回它的交换机，并确认虚拟机拿到了地址。不要把 VPN 适配器再接回去。在宣布完成之前，把模拟器和客户端再各测一次。

在受管工作站上，告诉管理员你改了哪个绑定。之后的策略刷新可能会恢复旧的连接，卡住的问题会毫无明显原因地回来。

记下适配器名称、它绑定的交换机，以及改动前后的 ipconfig 状态。如果更新之后又卡住，这份记录就是五分钟排查和从头再来之间的差别。