VirtualBox NAT 虚拟机 DNS 在宿主机加入 VPN 后失效

虚拟机有自己的解析器，NAT 网卡有两种 DNS 模式。先追踪一次查询，再判断宿主机解析器模式是否符合 VPN 策略。

在 Windows 宿主机上，VPN 一连接，内部应用名就能解析；在 Ubuntu 虚拟机里却不能。 虚拟机会保留自己的解析器设置，而它前面的 NAT 网卡可以用两种不同方式回答 DNS 查询。把虚拟机指向公共解析器能让网站重新加载，但内部名称仍然无法解析。所以在做任何修改之前，先追踪解析器路径。

通过 NAT 网卡追踪一次查询

选择一个内部完全限定名和一个公共名称作为对照。隧道建立后，在宿主机上确认内部名称能解析，并且其后的应用能够打开。然后在虚拟机内运行同样的两次查询，比较的是答案而不是工具。

继续之前，先确认网卡确实是普通 NAT。桥接网卡、命名 NAT 网络和虚拟机内的第二个 VPN 客户端各有自己的配置和解释。此时靠猜只会浪费剩下的排查时间。

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

第一条命令显示网卡模式以及任何与之相连的 NAT 网络。在 Ubuntu 虚拟机里，第二条命令列出各链路的 DNS 设置，第三条往往只显示一个本地 stub 地址，这意味着真正的上游在别处。

把解析和可达性分开。虚拟机拿到正确地址却打不开连接，问题在路由、过滤或服务权限，再改 DNS 也碰不到它。单独测试该地址，并记下两者中哪一个失败。

代理模式和宿主机解析器模式是不同的机制

在代理模式下，NAT 引擎把虚拟机的查询转发给它已经知道的 DNS 服务器。在宿主机解析器模式下，它拦截查询，并让宿主机操作系统用当前正在使用的解析方式来解析。只有第二种会跟随 VPN 客户端——隧道建立时，客户端会改写宿主机解析。所以两个设置在同一个机器上给出不同答案。

这个区别就是一句话概括的全部问题。给虚拟机一串服务器地址，和让 Windows 通过已配置的解析器解析名称，并不是一回事；在拆分 DNS 的 VPN 上，两种答案不同。网卡选项关乎机制，不关乎授权。

两种模式都不授予任何访问权限。授权存在于 VPN 策略和服务中，一次能用的查询只说明名称变成了地址。

切换网卡，然后确认虚拟机实际拿到什么

先记录虚拟机的网络和 DNS 设置，再关机，确保你修改的是持久配置。对于第一块网卡使用 NAT、名为 work-ubuntu 的虚拟机，要关机后才能从宿主机设置按网卡的选项。之后再开机并检查结果，而不是相信退出状态。

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

末尾的数字选择网卡编号，所以它不是通用值；设置 2 号网卡时该位置就是 2。使用与已安装 VirtualBox 版本匹配的 VBoxManage 可执行文件，因为路径上较旧的版本可能写入运行版本会忽略的设置。

改为启用代理选项会选到另一种机制，得不到宿主机解析器的行为。虚拟机启动后，检查它实际持有的 DNS 配置，因为虚拟机内固定的解析器或加密 DNS 设置会让应用走另一条路径，与网卡提供什么无关。

在 VPN 的整个生命周期内测试，而不只是一次

在虚拟机里重复两次查询，然后打开真实应用，让它验证 TLS 主机名。只用 IP 的连接测试能很好地隔离 DNS，但它不是证书检查，不应被当作证书检查来汇报。把名称、地址和应用结果一起记录下来。

在获批的时间窗口内断开并重新连接宿主机 VPN，再重复测试。结果应当符合访问策略；公共解析恢复工作，并不能说明私有查询是否留在预期路径上。

当宿主机解析器模式没有带来任何改变时，把记录的值改回去，并保留观察结果。排除 hypervisor 流量的 VPN 客户端、无法访问的内部解析器、虚拟机内固定的设置，各自需要不同的修正；把网卡改成桥接是改变网络设计，而不是重置 DNS。

相关文章