摘要虚拟机睡醒后突然断网ping 网关报Destination Host Unreachable、域名解析失败改 DNS 却毫无作用。本文通过ip neigh show定位到根因网关 ARP 解析失败INCOMPLETE而其他设备正常应答说明二层链路完好问题出在宿主机侧的vmnat.exe进程——它在宿主睡眠后带着失效的网络绑定继续运行“假活”导致网关与 DNS 同时消失。修复方法是在 Windows 宿主机上重启VMware NAT Service服务名VMnetNAT并在虚拟机内执行ip neigh flush清掉脏记录。文章还总结了ping 不通先看 ARP的排查方法论以及预防复发的若干措施。虚拟机突然断网、ping 网关报 Destination Host Unreachable别改 DNS是 VMware NAT 服务假死了一、现象虚拟机昨天用得好好的今天开机$ping-c3www.baidu.com ping: www.baidu.com: 域名解析出现暂时性错误 $ping-c3192.168.52.2 PING192.168.52.2(192.168.52.2)56(84)bytes of data. From192.168.52.128icmp_seq1Destination Host Unreachable From192.168.52.128icmp_seq2Destination Host Unreachable From192.168.52.128icmp_seq3Destination Host Unreachable ---192.168.52.2pingstatistics ---3packets transmitted,0received, 3 errors,100% packet loss第一反应是“DNS 坏了”毕竟报的是域名解析错误。于是去改/etc/resolv.conf、把 DNS 换成8.8.8.8、223.5.5.5……全都没用。而且虚拟机内部看起来一切正常$iplinkshow ens332: ens33:BROADCAST,MULTICAST,UP,LOWER_UPmtu1500qdisc fq_codel state UP... $ nmcli device status DEVICE TYPE STATE CONNECTION ens33 ethernet 已连接 netplan-ens33 lo loopback 未托管 --链路UP,LOWER_UPNetworkManager 也托管得好好的IP 也还在。但就是不通。二、先看一个关键细节报错是谁发的From 192.168.52.128 icmp_seq1 Destination Host Unreachable ^^^^^^^^^^^^^^^^ 这是本机自己的 IP这个 ICMP 错误不是网关回的是你自己的内核生成的。含义非常精确内核已经把包投到本地子网了但对网关192.168.52.2做ARP 解析时没有任何人应答→ 内核直接判定EHOSTUNREACH。所以问题不在 IP 层、不在路由层在二层 —— ARP 就没通。三、一条命令定位根因$ipneigh show|grep192.168.52.2192.168.52.2 dev ens33 INCOMPLETE192.168.52.254 dev ens33 lladdr 00:50:56:e1:00:a1 STALE这条输出把问题一刀切开了行含义.2→INCOMPLETE网关无人应答ARP 解析失败.254→ 有 lladdr另一台设备正常应答了 ARP第二条是决定性的既然.254能应答说明你的虚拟网卡、虚拟交换机、整条二层链路全都是好的。只有一个东西死了。四、为什么是“假死”而不是“崩溃”先建立一个关键认知vmnat.exe不是崩溃了是带着失效的网络绑定继续运行—— 也就是“假活”。VMware 虚拟网络里的“网关”和“DHCP 服务器”都不是硬件设备而是宿主机上的进程模拟出来的ARP 由它们代答虚拟地址代答进程Windows 上的服务192.168.x.2NAT 网关vmnat.exeVMware NAT Service192.168.x.254DHCP 服务器vmnetdhcp.exeVMware DHCP Servicevmnat.exe一个人干三份活代答网关.2的 ARP——.2这个地址是它虚构出来的做 NAT 转发—— 改写源 IP/端口借宿主机真实网卡把包发出去做 DNS 转发代理—— 所以 DHCP 下发给虚拟机的 DNS 服务器地址就是.2这三件事全靠它的“绑定”绑定到 VMnet8 虚拟网卡、绑定到宿主机物理网卡、维护 NAT 转换表。宿主睡眠的那一刻宿主进入睡眠 │ ├─ Windows 关闭 / 重新初始化物理网卡Wi-Fi 断连、以太网掉链 │ ├─ vmnat.exe 手里的 socket / 适配器句柄指向的是【睡眠前那块网卡】 │ ├─ 唤醒后网卡被重新初始化可能换了 IP、换了驱动绑定 │ └─ vmnat.exe 没有重新绑定 —— 仍然抱着旧句柄 → 三份活全部失效为什么服务管理器还显示「正在运行」这是整件事最阴险的地方Windows 的 SCM服务控制管理器只检查「进程是否还存在」不检查「它的网络绑定是否有效」。所以从系统角度看vmnat.exe活着、没报错、CPU 占用为零——一切正常。但它的内部状态句柄、NAT 表、网卡绑定已经全部过期作废。这就是“服务在跑、网卡已连接、IP 也在但就是不通”的原因。为什么 DNS 也一起挂了因为DHCP 下发给你的 DNS 服务器地址就是网关.2本身vmnat.exe兼任 DNS 代理。$ resolvectl status|grep-A2DNS ServersDNS Servers:192.168.52.2 ← 就是网关所以它一死网关和 DNS 同时消失—— ping 不通和域名解析失败两个症状其实是同一个根因。这也意味着照着DNS 报错去改 DNS 配置是徒劳的。包根本出不去换哪个 DNS 都没用。五、修复在 Windows 宿主机上重启服务注意这一步必须在宿主机上做在虚拟机里怎么改都没用。Win R→ 输入services.msc→ 回车找到VMware NAT Service→ 右键 →「重新启动」顺手确认两列看什么应该是什么不对就怎么改状态正在运行显示「已停止」→ 右键启动启动类型自动显示「手动」→ 属性里改成自动或者用管理员PowerShellRestart-ServiceVMnetNAT-Force⚠️ 注意服务显示名是 “VMware NAT Service”但服务名是VMnetNAT。命令行要用服务名。回虚拟机验证sudoipneigh flush dev ens33# ← 别省清掉那条 INCOMPLETE 脏记录ping-c3192.168.52.2ipneigh show|grep192.168.52.2# 这次应该变 REACHABLEping-c3www.baidu.comip neigh flush一定要执行 —— 不清的话那条INCOMPLETE记录可能还会被复用一小会儿让你误判成没修好。成功的样子192.168.52.2 dev ens33 lladdr 00:50:56:xx:xx:xx REACHABLE 64 bytes from 192.168.52.2: icmp_seq1 ttl128 time0.3 ms 64 bytes from 220.181.111.232: icmp_seq1 ttl128 time7.8 ms六、为什么重启就好了**重启 杀掉旧进程 全新启动。**新进程启动时会重新枚举宿主机上现有的网卡 → 拿到当前有效的网卡重新绑定 VMnet8 虚拟网卡重新注册192.168.52.2→ ARP 又开始有人应答了重建一张空的NAT 转换表旧的那些死端口映射被彻底丢弃在新网卡上重新打开 DNS 代理 socket你不需要改任何配置——配置一直是对的。坏的是“进程的内部状态”。换个新进程用同一份配置重新初始化就好了。七、会复发所以做这几件预防触发条件是宿主睡眠所以只要机器睡过它就可能再来一次。措施怎么做启动类型设对两个 VMware 网络服务设为「自动」更稳的是「自动延迟启动」安全软件放行⚠️ 360 / 火绒 / 电脑管家清理后台时会把这两个服务改成「手动 / 禁用」这是除休眠之外的第二大诱因务必加白名单关 Windows 快速启动控制面板 → 电源选项 → 选择电源按钮的功能 → 更改当前不可用的设置 → 取消「启用快速启动」网卡别省电设备管理器 → 网络适配器 → 属性 → 电源管理 → 取消「允许计算机关闭此设备以节约电源」唤醒后一键恢复把Restart-Service VMnetNAT -Force做成桌面快捷方式实在不行直接重启 Windows服务会随系统重新初始化八、一条可复用的方法论ping 不通先看 ARPping只能告诉你不通ip neigh show能告诉你断在哪一层观测结果结论nmcli device status显示unmanaged虚拟机内的配置层netplan 授权 / NetworkManagerip neigh里网关 INCOMPLETE但其他地址有 lladdr宿主机侧某个进程死了← 本文场景ip route没有 default路由层ARP 通、ping 不通三层以上防火墙 / ICMP 被禁 / 路由策略有 IP、能 ping 通 IP只有域名失败DNS 配置记住那个分水岭报错源是「本机 IP」→ 往外看宿主机设备状态是unmanaged→ 往里看虚拟机配置。九、最后一条更通用的经验这次的故障属于一个很常见的类型不只存在于 VMware长效进程daemon在系统状态变化睡眠、换网、改 IP之后内部状态过期但不自知。同一类的坑你以后还会遇到VPN 客户端睡醒后连不上同样的旧句柄问题Docker Desktop 睡醒后网络异常WSL2 睡醒后localhost转发失效通用套路先排除配置对不对再怀疑进程状态新不新最后才动配置。判断信号很简单 ——如果重启进程/服务就好了那故障一定在运行时状态层面而不是配置文件层面。这个判据能帮你在改配置和重启服务之间快速做对选择少走很多弯路。如果这篇帮你定位到了问题点个赞让更多人看到。评论区欢迎交流别的排查思路。
