群里又有人问虚拟机上不了网怎么办截图过来一看CentOS 7NAT模式虚拟机里ping网关通、ping外网不通。这种问题我在VMware里前前后后处理过几十次从最早傻乎乎地直接重装VMware到现在基本三分钟就能定位到根因中间踩过的坑足够凑一篇长文了。这篇就把NAT模式断网的常见原因、排查思路和修复方法一次说清楚。不管你是刚装好虚拟机的新手还是已经被断网折磨了好几天找不着头绪的老手按着下面的顺序来一遍大概率能救回来。排查过程不复杂难的是你不知道该先看哪里这篇文章就是来帮你把排查顺序理顺的。1. 先搞懂NAT模式的数据通路才知道断在哪一环1.1 NAT模式到底是怎么把网络借给虚拟机的很多人理解NAT模式就一句话虚拟机通过宿主机上网。话是没错但太笼统了。实际的数据通路比我下面写的还要多几个环节每个环节都可能成为断网的根源。在VMware里NAT模式默认对应的虚拟网络是vmnet8。虚拟机的流量走的是这么一条链路虚拟机虚拟网卡 → vmnet8虚拟交换机 → NAT设备宿主机上跑的vmnat.exe进程→ 宿主机物理网卡 → 互联网这条链路上有几个IP地址特别容易搞混我单独拿出来说清楚宿主机里那块叫VMware Virtual Ethernet Adapter for VMnet8的虚拟网卡IP是192.168.x.1它只是宿主机访问虚拟网络用的接口。虚拟机里的默认网关是192.168.x.2这个地址是NAT设备本身所有出网流量都要过它。虚拟网络里的DHCP服务器通常分配在192.168.x.254它负责给虚拟机发IP地址。很多人配置静态IP的时候把网关写成192.168.x.1这是错的。.1是宿主机侧的本机接口地址不是网关把网关写在这里虚拟机基本出不了网。正确网关永远是那个NAT设备也就是192.168.x.2。理解了这条链路你就明白为什么NAT模式断网的原因五花八门了链路太长任何一个环节掉链子表现都不一样。好在反过来想只要我们沿着这条链路从上到下逐个验证就一定能找到断点。1.2 断网的几种典型表现先对号入座我根据实际遇到的案例把NAT断网的表现归纳成下面几类你可以先对照一下自己属于哪种情况现象大概率故障点虚拟机内IP是169.254.x.x开头DHCP服务异常虚拟机没拿到地址虚拟机有IP但ping不通网关192.168.x.2vmnet8链路异常或NAT服务没起来ping得通网关但ping不通外网IPNAT服务异常或宿主机物理网络出问题ping外网IP通但域名全部解析不了DNS配置有问题网络时好时坏重启VMware后能撑一阵服务崩溃、MAC冲突或电源管理干扰宿主机熄屏或睡眠后虚拟机掉线宿主机电源管理把网络设备休眠了后面所有章节本质上都是在讲这些现象对应的修复方法。先对号入座能帮你省掉大量瞎试的时间。2. 按现象快速圈定故障范围宿主机还是虚拟机内部2.1 宿主机这边三分钟自检排查断网我习惯先从宿主机开始原因很简单宿主机是虚拟机网络的根基宿主机自己都上不了网虚拟机必然跟着断。这一步很快三分钟就能完成。Windows宿主机的自检命令如下在CMD或者PowerShell里运行ipconfig /all看两样东西第一物理网卡的IPv4地址是不是正常的有没有拿到内网地址第二有没有一个叫VMware Virtual Ethernet Adapter for VMnet8的网卡它的IP是不是192.168.x.1。如果这个虚拟网卡压根不存在或者显示媒体已断开连接那就说明VMware虚拟网络组件本身出了问题后面第七节的内容直接跳到那里去看。宿主机上网是否正常直接ping一个公共IP测试ping 223.5.5.5如果宿主机ping不通那先解决宿主机网络别在虚拟机上白费功夫。如果宿主机一切正常再往下走。2.2 虚拟机内部的网络自检宿主机没问题接下来进虚拟机。虚拟机里的网络自检我按固定顺序执行每一步都能缩小故障范围ip a先看虚拟网卡的状态是不是UP有没有拿到IP地址。注意看网卡名CentOS一般是ens33、ens160之类Ubuntu可能是enp0s3。如果是169.254.xx.xx开头直接跳到第四节。接着看路由表ip route正常情况默认路由应该指向192.168.x.2这个网关。如果路由表里压根没有default条目那就是网关配置丢了。然后按顺序ping三个目标ping 192.168.x.2 ping 223.5.5.5 ping www.baidu.com这三个ping结果组合起来基本就能锁定问题所在的层级了。2.3 从现象逆推故障源头的判断表我把上面的判断逻辑整理成一张表排查的时候拿着它对照就行虚拟机内现象判断结论该看哪一节IP是169.254.x.x没拿到DHCP地址第四节有IPping不通网关192.168.x.2vmnet8链路或NAT服务问题第三、七节网关通ping不通223.5.5.5NAT服务或宿主机物理网络问题第三节223.5.5.5通域名不通DNS解析故障第五节全部正常但应用上不了网防火墙或端口问题第六节这里有个细节要提醒ping 223.5.5.5通、ping www.baidu.com不通是最多人碰到的情况也是最好修的情况就是DNS配置的事别去折腾网关和NAT服务方向错了浪费时间。3. VMware的NAT/DHCP服务罢工高频故障的第一嫌疑3.1 两个关键服务分别管什么在Windows宿主机上VMware靠几个后台服务撑起虚拟网络其中跟NAT模式断网关系最大的是两个VMware NAT Service对应的进程是vmnat.exe负责网络地址转换。虚拟机发出的数据包由它改写成宿主机能发出去的数据包外网回包也由它接收并转发给虚拟机。VMware DHCP Service对应的进程是vmnetdhcp.exe负责给vmnet8网络里的虚拟机动态分配IP地址。还有一个VMware Authorization Service它管的是VMware整体的权限问题偶尔也会影响虚拟网络但优先级低于前两个。为什么这两个服务是NAT断网的头号嫌疑因为在Windows系统里跑的用户态服务很容易因为系统睡眠唤醒、Windows更新、被杀软误拦等原因突然挂掉或者假死。我处理过的NAT断网案例里一半以上最后都指向这里。3.2 服务卡死后的正确重启姿势检查方法很简单在Windows宿主机上按WinR输入services.msc回车找到VMware NAT Service和VMware DHCP Service看状态是否为正在运行。如果状态是已停止直接右键启动。如果是正在运行但虚拟机就是上不了网那就需要重启服务。用管理员权限打开CMD按下面的顺序执行net stop VMware NAT Service net stop VMware DHCP Service net start VMware DHCP Service net start VMware NAT Service我的习惯是先停NAT服务再停DHCP服务启动时反过来先启DHCP再启NAT。这样可以保证NAT服务起来的时候DHCP服务已经就绪避免虚拟机在NAT启动后立刻去要IP却没人应答的情况。重启完服务回到虚拟机里重新ping一下网关大概率就好了。如果服务重启后还是不行把vmnet8网卡禁用再启用一次往往能起到清理虚拟网卡状态的作用。在Windows宿主机上打开网络连接找到VMware Virtual Ethernet Adapter for VMnet8右键禁用再右键启用。3.3 服务反复崩溃的深层原因如果服务停了你启动过一会儿又停了这种反复崩溃的情况不能靠手动重启解决得找根因。根据我遇到的案例常见原因有几个第一宿主机频繁睡眠唤醒。Windows电源管理把虚拟网络服务搞死的概率很高尤其是开启了快速启动的情况。第二其它虚拟化软件冲突比如同时装了VirtualBox或者Windows自带的Hyper-V它们会抢占网络组件。第三杀毒软件把vmnat.exe当成了可疑进程。如果是电源管理的问题去看第八节的防断网习惯。如果是软件冲突建议同一台机器上只保留一个虚拟化平台的主力工具别让它们混用。如果是杀软误拦需要把VMware整个安装目录加入信任区。还有一个容易被忽略的情况VMware服务启动失败时最好去事件查看器eventvwr.msc里看Windows日志里面会明确记录服务启动失败的错误码。按错误码搜索比瞎猜高效得多。4. 虚拟机网卡与IP层异常排查从169.254地址说起4.1 DHCP租约过期最典型的IP层故障虚拟机的IP变成169.254开头的地址这是最典型的IP层故障信号。在Windows里这种地址叫APIPA自动专用IP地址在Linux里也一样。它的意思是网卡配置成了自动获取IP但DHCP服务器没有应答系统只好自己给自己分配了一个假地址用来保证网卡处于已连接状态。拿到169.254地址说明虚拟机的DHCP请求根本没得到回应。这时候先确认宿主机上的VMware DHCP Service是否在运行如果服务正常就在虚拟机里手动重新获取一次地址。Windows虚拟机执行ipconfig /release ipconfig /renewLinux虚拟机执行dhclient -r dhclientUbuntu里也可以直接重启网络管理服务systemctl restart NetworkManager我遇到过一种特殊情况DHCP服务正常但虚拟机就是一直拿不到地址。最后发现是这台虚拟机是从模板克隆出来的克隆时保留了原模板的MAC地址而原模板虚拟机还开着两台机器在同一个vmnet8里抢一个IP导致DHCP响应混乱。这种问题在下面详细说。4.2 MAC地址冲突隐藏的暗坑克隆VMware虚拟机时如果采用的是完整的虚拟机复制而不是用克隆向导新的虚拟机可能会沿用源虚拟机网卡的MAC地址。两台相同MAC的虚拟机同时开机接入vmnet8表现就是一会儿这台能上网一会儿那台能上网严重时两台都不正常。排查方法很简单看看是不是有多台虚拟机的MAC地址一模一样。处理起来也直接在VMware Workstation里选中虚拟机打开编辑虚拟机设置找到网络适配器点开高级把MAC地址改成生成Generate一个新的。改完重启虚拟机让它重新用新MAC去DHCP拿一次地址就好。如果你习惯直接编辑.vmx文件也可以把ethernet0.addressType改成generated然后删掉ethernet0.address这一行保存重新打开虚拟机。别小看这个坑我在帮别人处理断网问题时至少遇到过三次因为克隆导致MAC冲突的情况。4.3 手动配置静态IP的正确姿势有些人喜欢给虚拟机配静态IP省得每次DHCP分配的地址都变。静态IP配置本身不复杂但有几个细节必须注意否则配出来就是个上不了网的地址。第一确保你选的IP不在DHCP自动分配范围内或者至少要确保没有别的虚拟机占用。我习惯让DHCP管一段静态IP用另一段比如DHCP分配范围是192.168.x.128到192.168.x.254静态IP就挑192.168.x.10到192.168.x.100之间的地址。第二网关必须写192.168.x.2不是192.168.x.1这一点前面强调过了这里再重复一次因为太容易错。CentOS 7/8里编辑网卡配置文件vi /etc/sysconfig/network-scripts/ifcfg-ens33改成BOOTPROTOstatic IPADDR192.168.x.100 NETMASK255.255.255.0 GATEWAY192.168.x.2 DNS1192.168.x.2 DNS2223.5.5.5保存后重启网络systemctl restart networkUbuntu 20.04以上用netplan编辑/etc/netplan/下的yaml文件network: version: 2 ethernets: ens33: dhcp4: no addresses: [192.168.x.100/24] routes: - to: default via: 192.168.x.2 nameservers: addresses: [192.168.x.2, 223.5.5.5]然后sudo netplan apply。DNS这里我习惯把NAT网关192.168.x.2作为首选DNS它本身带转发功能能解析域名。如果遇到DNS解析问题再加一个公共DNS兜底。5. 能ping通但上不了网DNS解析故障的定位与修复5.1 为什么ping通不等于网络正常能ping通IP但打不开网页、上不了网这是最迷惑人的一种故障。大家下意识觉得能ping通不就代表网络通了吗其实完全不是一回事。ping用的是ICMP协议走的是IP层的连通性测试。而在NAT模式下只要NAT服务和路由没问题你ping任意一个IP地址都能通。但域名解析走的是另一条路系统要把www.baidu.com这类域名通过DNS服务器解析成IP地址然后才能发起HTTP请求。如果DNS服务器配置错误或者DNS服务不可用那么ping IP是通的但任何域名都访问不了浏览器里全是无法解析服务器的DNS地址。所以判断方法很简单在虚拟机里执行ping 223.5.5.5 ping www.baidu.com如果第一个通、第二个不通直接定位为DNS问题别再排查网关和NAT了。既浪费时间又找不到答案。5.2 虚拟机里DNS配置的修改方法DNS配置在哪改取决于虚拟机的发行版和网络管理方式。CentOS系看/etc/sysconfig/network-scripts/ifcfg-ens33把DNS1和DNS2写对就行。上面4.3节已经给了完整的配置示例这里不再重复。如果你用的是NetworkManager管理网络可以用nmcli直接改比改文件更方便nmcli con mod ens33 ipv4.dns 223.5.5.5 114.114.114.114 nmcli con mod ens33 ipv4.ignore-auto-dns yes nmcli con up ens33改完记得查看一下/etc/resolv.conf确认nameserver行是否已经更新。如果这个文件里写的不是刚才设置的DNS而是被某个服务自动覆盖了那说明你的系统里有一个DNS自动管理的机制在接管最常见的代表就是下面要讲的systemd-resolved。5.3 systemd-resolved带来的新坑Ubuntu从18.04开始默认启用systemd-resolved服务它接管了系统DNS解析/etc/resolv.conf变成了指向127.0.0.53这个本机回环地址的软链接。很多人第一次遇到时一头雾水明明配置了DNS为什么resolv.conf里看不到在这种系统上查看实际生效的DNS要用这个命令resolvectl status或者老一点的版本用systemd-resolve --status这个命令会显示每个网卡上配置的DNS服务器。如果这里显示的DNS不对或者没有处理办法有两种。一种是在netplan里给网卡明确指定nameservers然后netplan apply另一种是直接改/etc/systemd/resolved.conf在[Resolve]段下设置DNS和FallbackDNS[Resolve] DNS223.5.5.5 114.114.114.114 FallbackDNS192.168.x.2改完重启服务systemctl restart systemd-resolved改完再ping一次www.baidu.com确认。需要提醒的是如果你在网卡层面已经指定了DNSsystemd-resolved会优先用网卡的配置所以改/etc/systemd/resolved.conf不一定生效这时还是回到netplan里去改。我在Ubuntu虚拟机里排查DNS问题时八成以上都是通过改netplan解决的。6. 防火墙与安全软件拦截两头都要查的隐藏坑6.1 虚拟机内部防火墙的干扰前面所有排查都做完了网络看起来一切正常但应用就是连不上这时候要怀疑防火墙。虚拟机的防火墙默认规则可能阻止了对外访问尤其是有些定制镜像默认开了严格规则。Linux虚拟机里先看防火墙状态systemctl status firewalld ufw status如果是firewalld临时停掉测试systemctl stop firewalld如果是ufwufw disable停掉防火墙后再试网络。如果恢复正常说明就是防火墙规则拦的。注意别为了方便直接永久关闭防火墙正确做法是找到被拦截的流量方向放行对应的服务。比如NAT模式里虚拟机要访问外网的HTTP/HTTPS端口正常情况下防火墙默认放行出站流量如果你之前手动加过出站限制需要把80、443等端口加进白名单。Windows虚拟机也一样Windows Defender防火墙可能会拦截某些程序或者整个网络流量。在测试阶段可以先临时关闭域网络和专用网络的防火墙开关确认是否防火墙导致的问题。确认后记得把需要放行的程序加入防火墙允许列表而不是一直关着防火墙裸奔。6.2 宿主机安全软件与Windows防火墙的拦截虚拟机内部查完了别忘了宿主机这一侧也可能在搞鬼。宿主机上运行的第三方安全软件尤其是带了上网防护网络防护这类模块的很容易把vmnat.exe、vmnetdhcp.exe当成可疑的网络进程拦下来。表现就是虚拟机里时断时续过一会儿彻底断网重启VMware服务又好一阵子。我在帮朋友处理一个顽固断网问题时宿主机、虚拟机、服务全都正常最后关掉宿主机安全软件的网络防护开关虚拟机立刻恢复了。定位方法很朴素暂时退出宿主机上的安全软件看虚拟机网络是否恢复恢复了就说明是它拦的然后把VMware整个安装目录加入信任区再重新开启防护。Windows自带的防火墙也可能是元凶。打开允许应用通过Windows防火墙确认VMware相关的程序vmware.exe、vmnat.exe、vmnetdhcp.exe等是否在允许列表里。很多人在安装VMware时防火墙弹窗没注意直接点了取消后面就会踩这个坑。7. 虚拟网络编辑器重置最后的万能药与它的副作用7.1 重置前先备份别让简单问题变复杂如果上面几层都查过了还是解决不了最后一招就是重置虚拟网络。但这里我必须先泼一盆冷水虚拟网络编辑器里的恢复默认设置按钮威力极大它会把你自定义的NAT网段、端口转发规则、DHCP地址范围全部清空回到VMware安装时的初始状态。很多人不知道这点点完才发现自己之前配置的端口映射全没了。所以点恢复默认之前先把这个界面里的所有配置记下来。在VMware Workstation里打开编辑→虚拟网络编辑器点击右下角的更改设置按钮。然后分别打开NAT设置和DHCP设置把以下几项截图或者抄下来vmnet8当前的子网网段比如192.168.x.0NAT设备地址网关默认192.168.x.2DHCP分配范围起始地址和结束地址端口转发里的每一条规则如果有的话这些信息是重置后你必须手动恢复的不记下来的话重置完再想配回来就只能凭记忆了。7.2 恢复默认设置的正确打开方式确认记录完配置再执行重置。步骤是这样的关闭VMware Workstation里所有正在运行的虚拟机最好连VMware主程序也一起退出。重新打开VMware Workstation进入编辑→虚拟网络编辑器。点击更改设置输入管理员权限确认。点击恢复默认设置等待它重新生成虚拟网络。恢复完成后按需重新配置NAT网段、DHCP范围和端口转发。回到宿主机网络连接里确认vmnet8虚拟网卡已经重新出现且启用。确认VMware NAT Service和DHCP Service都在运行状态。启动虚拟机重新获取IP测试网络。这里有个容易踩的细节恢复默认设置之后虚拟机的网络适配器可能还停留在旧的网络状态。建议先在虚拟机关机状态下把网络适配器从NAT模式切到自定义再切回NAT模式强制重新初始化一次网卡连接。7.3 重置后的网络参数核对清单重置完成后别急着关掉界面按照这份清单逐项核对一遍确认没问题再继续用vmnet8是启用状态且子网网段和之前一致如果你有自定义。NAT设置里网关IP是192.168.x.2DHCP启用勾上了。宿主机上的VMware Virtual Ethernet Adapter for VMnet8的IP是192.168.x.1。VMware NAT Service和DHCP Service都在运行。虚拟机网络适配器选择了仅主机模式或NAT模式中的正确选项断网排查的对象是NAT就确保选的是NAT。虚拟机重新获取的IP在新的DHCP范围内网关和DNS配置正确。进到虚拟机里再跑一遍第二节的ping测试流程。如果到这里虚拟机还是上不了网那基本可以排除虚拟网络配置层面的问题得往更深的地方挖了比如VMware安装本身是否损坏、是否和Windows系统组件有底层冲突。这种场景下卸载重装VMware反而比重试各种设置更高效。8. 一个真实断网案例的完整排查过程与日常防断网习惯8.1 一次完整的断网抢救记录分享一个我印象很深的实际案例它几乎串起了前面所有知识点。有一次我手上一台CentOS 7虚拟机用的NAT模式正常情况下跑得好好的。某天早上开机发现上不了网了现象是能ping通网关192.168.x.2但ping 223.5.5.5完全没反应。我当时的排查顺序是这样的先看宿主机ipconfig确认物理网卡正常宿主机能正常上网排除了宿主机网络问题。再看虚拟机的IP和路由IP正常路由表正常默认网关指向192.168.x.2没问题。按逻辑网关通但外网不通问题应该出在NAT服务或宿主机物理网络的转发上。打开services.msc一看VMware NAT Service是已停止状态VMware DHCP Service还在运行。我当时以为找到根因了右键把NAT服务启动起来回到虚拟机里再ping结果还是不通。这就有点诡异了服务都起来了怎么还不行。后来我注意到一个细节vmnet8虚拟网卡在宿主机上是启用的但IP显示成了169.254.x.x说明vmnet8网卡和NAT服务之间没有正常握手。解决办法是先把vmnet8网卡禁用再启用等它重新拿到192.168.x.1的IP地址然后再回虚拟机ping了一遍外网通了。这个案例说明两个问题第一NAT服务停掉只是表象它为什么会停才是关键第二服务恢复后vmnet8网卡的状态未必会自动恢复有时候需要手动触发一次网卡的重置。后来我查了Windows事件日志发现前一天宿主机经历过一次意外的睡眠唤醒正是那次唤醒把NAT服务干掉了。8.2 我用下来最有效的防断网习惯断网问题防大于治下面这几个习惯是这几年用下来最能降低断网几率的直接照做就行。第一关闭Windows快速启动。快速启动虽然能加快开机速度但它对驱动程序和服务状态的恢复并不总是友好经常导致网络服务异常。在控制面板的电源选项里找到选择电源按钮的功能点击更改当前不可用的设置把启用快速启动前面的勾去掉。第二宿主机不要频繁睡眠尤其不要带着虚拟机挂起。宿主机睡着再唤醒虚拟机网络重启的概率极高。如果确实需要离开一会儿建议先把虚拟机里的系统正常关机或者用VMware的挂起功能而不是直接让宿主机睡眠。第三针对熄屏断网的情况把电源计划里的PCI Express和无线适配器设置如果你用无线网络的节能模式改成最高性能。更直接的做法是在设备管理器里找到宿主机正在用的物理网卡右键属性→电源管理取消勾选允许计算机关闭此设备以节约电源。我在处理电脑熄屏后会断网这类问题时这个选项是最常见的元凶。第四克隆虚拟机之后第一时间去网络适配器里重新生成MAC地址避免两台机器MAC冲突。这个习惯能省掉一大堆稀奇古怪的间歇性断网问题。第五VMware Workstation和VMware Tools保持更新。很多断网问题其实是老版本网络模块的bug新版本早就修了但你不更新就永远踩在坑里。第六从外部强制关闭VMware进程的次数越少越好。直接结束进程很容易让虚拟网络服务处于半挂起状态下次开机就可能断网。宁可等虚拟机正常关机也不要图省事强制结束。有人可能会问NAT模式断网问题是不是只有VMware才有其实不是VirtualBox和Windows自带的Hyper-V的NAT模式也有类似的毛病只是服务和配置文件的名字不同排查思路是相通的先看链路哪一层断了再看服务进程活没活最后检查网卡配置和DNS。这套方法学会之后换哪个虚拟化平台都不慌。