主机 VPN 连接后 Hyper-V 客户机丢失 DNS

客户机今早还好好的。随后主机启动了 Cisco AnyConnect，VM 便丢失了 DNS、域信任和共享文件夹，而它内部没有任何改动。主机隧道与客户机网络是两条独立路径，接通一条不会搬动另一条。请从客户机内部向外排查，并在动手之前先记录所见。

客户机还能看到什么

在 VM 中记录地址、默认网关和解析器，主机连接前一次、连接后一次。只保住地址而丢失名称解析的客户机，问题在解析器。从未有过路由的客户机，问题在路径，两者需要不同的处理。从主机侧无法区分它们，所以读取必须来自内部。

这三项读数各取两次，就是你的基线。之后的一切都对照它们衡量。

客户机走的是哪个出口

Hyper-V 用两条命令回答这个问题：Get-VMSwitch 列出交换机，Get-VMNetworkAdapter -VMName TestVM 显示客户机所连接的那一个。Default Switch 是 Windows 管理的 NAT 网络；外部交换机把流量交给物理适配器；内部交换机在有人添加 NAT 或路由器之前不承载任何东西。VirtualBox 用 NAT、NAT Network 和 bridged 表达同样的三个概念。

模式决定主机隧道究竟能不能起作用。NAT 客户机由 WinNAT 转换，再由主机协议栈转发，因此遵循主机的路由表；使用全隧道客户端时，它的流量就是进入 VPN 适配器的流量，当客户端封锁本地子网时会被丢弃。接在外部交换机上的桥接客户机根本到不了主机路由：它的帧直接离开物理网卡，因此既绕过隧道，也绕过客户端的本地局域网策略。

与 Hyper-V 共享主机隧道

如果客户机需要隧道却无法运行自己的客户端，Windows 可以共享 VPN 连接。打开 VPN 适配器的属性，进入“共享”，允许其他网络用户通过它连接。把家庭网络连接指向 Hyper-V 适配器，vEthernet (Default Switch)，然后从客户机内部测试新的请求。

把这种安排当作实验性修复，因为它的表现就是如此。断开、重连或主机重启后都必须重新应用。在某些 Windows 11 版本中，下拉列表里根本没有该适配器，那时这条路就走不通。

重装 Hyper-V 功能救活过几个顽固的客户机。把这一步留到最后，并先记录客户机状态。

子网被过滤时的端口转发

过滤客户机 NAT 子网的主机 VPN 破坏的是直接访问，而不是名称解析。VM 明明在运行，ssh [email protected] 却卡住不动，而虚拟机监控程序的转换仍在工作。转发工作所需的端口，改为连接主机地址。下面的 Vagrantfile 行覆盖 SSH 和一个 HTTPS 服务；两者都要在重新加载前加入。

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

名称解析是另一个决定，值得单独修复。为该 NAT 适配器启用主机解析器功能，或者在客户机内部手动配置内部 DNS 服务器。把客户机指向公共解析器会让浏览恢复正常，却会破坏所有内部名称，这比故障更糟，因为它看起来像成功。请测试一个只有内部解析器才知道的名称。

确认它生效的检查

做完上述任何改动后，在主机 VPN 已连接的状态下从客户机内部发起新请求，而不是之前。重连后和重启后都要重新检查共享，因为只扛得住其中一种的修复不算修复。确认客户机的解析器列表与其流量实际使用的网络一致。然后从主机地址测试端口转发，因为从客户机测试证明不了任何事。在客户机内部，两项 PowerShell 检查覆盖解析器和转发端口：

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

记录每一次交换机或驱动程序改动及其回退步骤。Microsoft 的 Hyper-V NAT 指南 解释了 Default Switch 究竟是什么，在创建与之冲突的第二套 NAT 网络之前值得一读。