ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

VMware虚拟机断网排查:桥接、NAT与仅主机分层定位

VMware虚拟机断网排查:桥接、NAT与仅主机分层定位

虚拟机开机,网卡图标是亮的,ping网关超时,浏览器一直转圈,宿主机这边网页刷得飞起。这个场景我每年至少撞上十几次,有时候是自己手贱改了虚拟网络编辑器的配置,有时候是笔记本换了无线网、有时候干脆是系统更新之后虚拟网卡被悄悄禁用了。VMware Workstation 虚拟机连不上网,听着像个小毛病,真排查起来能把人耗掉一下午,因为它的故障点横跨宿主机物理网卡、VMware 虚拟网络层、客户机操作系统三层,任何一层掉链子,表现都是同一个“上不了网”。

这篇东西不讲概念科普,讲的是我这些年实际排障时用的那套顺序和方法:先把三种网络模式(桥接、NAT、仅主机)的本质区别掰开,再按“宿主机 → 虚拟网络 → 客户机”的顺序一层层往下压,最后给一张症状对照表,让你在五分钟内锁定大概位置。刚装完虚拟机的新手能照着走完整个流程,跑了好几台虚拟机、开始折腾双网卡和内网环境的老手,也能在中间几节里找到几个容易忽略的点。全程实操,命令可以直接抄。

1. 三种网络模式的本质区别与选型逻辑

1.1 桥接、NAT、仅主机到底差在哪

很多人排查半天没结果,根子在于没搞清楚自己用的是哪种模式,以及这种模式在网络拓扑里到底站在什么位置。这三种模式的差别,用一句话概括:虚拟机在网络上“像谁”。

桥接模式下,虚拟机在网络里被当成一台独立的物理机。它有自己的 MAC 地址,直接向你所连的那个路由器要 IP,拿到的地址段和宿主机完全一样,同一局域网里的其他设备能直接访问它,它也能被路由器看见。优点是“真”,做局域网联调、跑服务给别人访问,非它不可;缺点是依赖物理网络环境,公司网络如果做了端口安全或者只允许特定 MAC 上网,虚拟机就会被拦在门外。

NAT 模式下,VMware 在宿主机内部搭了一个小型路由器,虚拟机连的是这个虚拟路由器,宿主机相当于这个虚拟网络对外的唯一出口。虚拟机拿到的是私有网段地址(默认常见 192.168.x.0/24),所有出网流量由 VMware 的 NAT 服务做地址转换后,借用宿主机的网络发出去。好处是虚拟机完全不依赖物理网络环境,换个 Wi-Fi、换个网线,虚拟机照常上网;坏处是外部设备主动连不进来,除非你手动做端口映射。

仅主机模式顾名思义,虚拟机只能和宿主机通信,压根没有出网的口子。它的用途是做隔离环境,比如测试一套内网服务、跑一些不想让它碰外网的东西。很多人选了仅主机模式然后抱怨上不了网,这属于配置意图和实际需求没对齐,不是故障。

对比项桥接模式NAT 模式仅主机模式
虚拟网络标识VMnet0VMnet8VMnet1
虚拟机 IP 来源物理路由器分配VMware 虚拟 DHCP 分配VMware 虚拟 DHCP 分配
默认网段与宿主机同段192.168.x.0/24192.168.x.0/24
能否访问外网能能不能
局域网他人能否访问虚拟机能默认不能不能
受物理网络策略影响大小无
典型适用场景服务联调、模拟真实主机日常开发、临时测试内网隔离、攻防练习环境

我自己的习惯是:日常开发用 NAT,需要给别人演示或者模拟多机集群时切桥接,做纯内网实验才用仅主机。这个默认选择能避开八成的麻烦。

1.2 为什么出厂默认配置经常连不上

刚装好的虚拟机默认就是 NAT,按理说开箱即用。但实际环境里翻车的概率不低,原因通常不在 VMware 本身,而在宿主机那边有几个“隐形开关”。

第一个是虚拟网卡被禁用。Windows 上安装 VMware 时会生成两块虚拟网卡:VMware Network Adapter VMnet1 和 VMnet8。NAT 模式能不能通,很大程度取决于 VMnet8 这块网卡的状态。系统优化工具、某些安全软件、甚至手动整理网络适配器时,它很容易被顺手禁用,而它的图标藏在“网络连接”面板里,平时根本看不见。

第二个是后台服务没起来。VMware 装了两个关键服务:VMware DHCP Service 和 VMware NAT Service。前者负责给虚拟机发地址,后者负责做地址转换。这两个服务默认是自动启动,但电脑非正常关机、系统更新、或者某些清理工具“优化开机项”之后,它们可能变成手动甚至被停掉。服务没跑,虚拟机自然拿不到 IP,表现就是一直卡在获取地址。

第三个是虚拟网络编辑器的配置被改乱。这块最容易出在“还原默认设置”被误点,或者曾经手动改过网段、子网掩码,导致虚拟 DHCP 的地址池和虚拟网卡不在一个网段。

还有一个容易被忽略的是宿主机装了别的虚拟化软件。比如 Windows 自带的虚拟化平台组件开启之后,会接管一部分网络栈,可能让 VMware 的桥接模式失效,或者让虚拟网卡出现异常。

1.3 我习惯的排查顺序:从物理层往应用层推

排障最忌讳的是东一榔头西一棒子。我固定用这套自上而下的顺序:

第一步,确认宿主机自己能上网。这听着像废话,但真有宿主机本身就在断网、或者连的是需要认证的访客 Wi-Fi 的情况,你在虚拟机里折腾一小时都是白费。

第二步,确认虚拟机的网络适配器是否“已连接”。虚拟机设置里那个“已连接”和“启动时连接”两个勾,缺一个都不行。这个勾被某次误操作取消之后,虚拟机内部的网卡就是“未插入网线”的状态,你怎么配 IP 都没用。

第三步,确认虚拟网络层的参数。也就是虚拟网络编辑器里的网段、DHCP 范围、NAT 网关地址,以及宿主机那两块虚拟网卡是否启用。

第四步,才进客户机内部查。看 IP 有没有拿到、网关对不对、DNS 配没配、路由表正不正常。

这个顺序的道理很简单:网络是分层的,下层不通的时候,上层怎么改都是无效操作。我见过太多人在客户机里反复执行ipconfig /release,而他宿主机上的 VMnet8 压根就是禁用状态。

2. 动手之前:宿主机侧的五个必查点

2.1 虚拟网卡有没有被禁用或带感叹号

Windows 上按Win + R输入ncpa.cpl,直接打开“网络连接”面板。这里应该能看到至少两块 VMware 开头的虚拟网卡。要看的就三件事:图标是彩色还是灰色、名字下面有没有“已禁用”字样、有没有黄色感叹号。

灰色带“已禁用”的,右键启用就行。有黄色感叹号的,说明驱动层面出了问题,通常是 VMware 安装损坏或者和系统更新冲突。这种情况我的处理方式是先右键“禁用”再“启用”试一次,不行就去设备管理器里卸载这块虚拟网卡,然后在虚拟网络编辑器里点一次“还原默认设置”,让 VMware 重新生成。注意,还原默认设置会把你自定义的所有虚拟网络一并重置,如果之前配过特殊网段,得提前记下来。

还有一个细节:VMnet1 和 VMnet8 的 IP 是 VMware 自动分配的,正常情况下 VMnet8 会是一个固定网段的地址,比如 192.168.x.1,这个地址其实就是虚拟 NAT 网络的网关在宿主机这一侧的映射。如果你发现 VMnet8 拿到了一个 169.254 开头的地址,那是自动私有地址,说明它没能和虚拟 DHCP 通信,基本可以判定 DHCP 服务有问题。

2.2 那两个后台服务是不是在跑

按Win + R输入services.msc,在列表里找 VMware 开头的服务,重点看两个:

  • VMware DHCP Service:负责给虚拟网络里的机器分配 IP。
  • VMware NAT Service:负责 NAT 模式下的地址转换。

启动类型应该是“自动”,状态应该是“正在运行”。如果状态是空的,右键启动;如果启动类型是“手动”或者“已禁用”,改成自动再启动。有些优化工具会把它们改成手动,结果就是每次重启电脑之后虚拟机都上不了网,得手动去开一次,这个坑我踩过不止一次。

顺便说一句,这两个服务启动失败的时候,事件查看器里通常会有记录。如果反复启动失败,大概率是 VMware 安装文件损坏,重装一遍客户端比继续折腾省时间。

2.3 虚拟网络编辑器里的关键参数怎么看

在 VMware Workstation 菜单里打开“编辑 → 虚拟网络编辑器”,注意这一步需要点“更改设置”按钮提权,否则看到的是只读状态,很多人卡在这儿以为按钮坏了。

打开之后看三个地方:

第一,看 VMnet0、VMnet1、VMnet8 分别对应哪种模式。列表里每一行都标了“桥接”“NAT”“仅主机”,如果发现 VMnet8 被改成了仅主机,那 NAT 模式当然上不了网,改回来就行。

第二,看 VMnet8 的“NAT 设置”。里面有个网关 IP,默认是网段里的.2地址。这个地址必须和虚拟 DHCP 分配的地址池在同一网段,否则虚拟机拿到 IP 也找不到网关。

第三,看“DHCP 设置”。里面能看到起始 IP、结束 IP 和租约时间。有次我遇到的问题是地址池只剩几个可用地址,而机器上开了七八台虚拟机,后开的几台就一直拿不到地址。把池子范围改大一点,比如从 x.100 到 x.254,问题立刻消失。

3. NAT 模式断网的完整实操排查

3.1 从宿主机到虚拟机的连通性分层验证

NAT 模式的排查,我固定按“四跳”来 ping,每一跳对应一个层次,跳不过去就说明问题卡在这一层。

第一跳:宿主机 ping 虚拟机的 IP。先在客户机里执行ipconfig(Windows)或ip addr(Linux)拿到地址,比如 192.168.152.128,然后在宿主机上ping 192.168.152.128。通不了,说明虚拟网卡 VMnet8 和虚拟机之间的链路有问题,回去查 2.1 和 2.2 那两节。

第二跳:虚拟机 ping 自己的网关。网关地址在虚拟网络编辑器的 NAT 设置里能看到,默认通常是192.168.152.2。这一跳不通,说明虚拟机的 IP 配置和虚拟网络不在一个网段,或者虚拟机内部防火墙把 ICMP 拦了。

第三跳:虚拟机 ping 一个公网 IP。比如ping 114.114.114.114。能通说明地址转换链路正常,问题出在域名解析上;不通说明 NAT 服务或者宿主机的出网链路有问题。

第四跳:虚拟机 ping 一个域名。比如ping www.example.com。前三跳都通,这一跳不通,那就是 DNS 的锅,去查 3.3 那一节。

# Linux 客户机上的四跳验证 ip addr show # 看拿到的 IP 和网段 ip route show # 看默认网关是否正确 ping -c 4 192.168.152.2 # 跳 2:网关 ping -c 4 114.114.114.114 # 跳 3:公网 IP ping -c 4 www.example.com # 跳 4:域名解析

这套四跳法最大的价值是快速排除无效路径。很多人一上来就在虚拟机里改 DNS,改了半天发现连网关都不通,白忙活。

3.2 DHCP 拿不到地址时的两种修法

DHCP 拿不到地址的典型表现是:客户机显示“未识别的网络”,ipconfig出来一个 169.254 开头的地址,或者 Linux 上ip addr显示NO-CARRIER或者干脆没有 IPv4 地址。

第一种修法是刷新租约。Windows 上依次执行:

ipconfig /release ipconfig /renew ipconfig /flushdns

Linux 上用nmcli或者重启 NetworkManager:

sudo nmcli networking off && sudo nmcli networking on # 或者 sudo systemctl restart NetworkManager

第二种修法是手动指定静态地址。当虚拟 DHCP 服务怎么都起不来,又急着用的时候,直接绕过它。参数参考这张表:

参数项建议值说明
IP 地址192.168.x.128 附近避开 DHCP 地址池,避免冲突
子网掩码255.255.255.0与虚拟网络编辑器里的掩码一致
默认网关192.168.x.2以 NAT 设置里显示的为准
首选 DNS114.114.114.114公共 DNS,稳定可用
备用 DNS223.5.5.5主 DNS 失效时兜底

注意,静态 IP 一定要避开 DHCP 的地址池范围,否则可能出现“两台机器抢一个地址”的诡异现象,表现为时通时不通,非常难查。

3.3 DNS 配错导致的“能ping通但打不开网页”

这是最经典的一种“假断网”。前三跳全通,浏览器就是打不开页面,报“找不到服务器”或者“DNS 解析失败”。

Linux 上先看三处:

cat /etc/resolv.conf # 最直接,看 nameserver systemd-resolve --status # 用 systemd 的系统看实际生效的 DNS nmcli dev show | grep DNS # 看 NetworkManager 下发的 DNS

/etc/resolv.conf有一个坑:在某些发行版上它是个软链接,由 NetworkManager 或者 systemd-resolved 动态生成,你手改完重启网络就被覆盖了。正规做法是改网卡配置或者用nmcli设置,而不是直接编辑这个文件。我在用的一些新版发行版上,/etc/resolv.conf甚至指向127.0.0.53,这是本地解析服务,真正的上游 DNS 得用resolvectl查。

sudo resolvectl dns # 查看各网卡的上游 DNS sudo resolvectl dns eth0 114.114.114.114 # 临时指定

Windows 上排查更简单,nslookup一试就知道:

nslookup www.example.com nslookup www.example.com 114.114.114.114

第一次失败第二次成功,那就是 DNS 配置的问题,去网卡属性里把 DNS 手动指定成公共地址即可。

另外一个隐蔽的情况是虚拟机里改了 hosts 文件。之前调试时加过一条域名映射,忘了删,结果那个域名永远解析到一台已经不存在的机器上。排查时顺手cat /etc/hosts看一眼,省事。

3.4 一键重建 NAT 网络的正确姿势

如果上面几招都无效,或者你确实把配置改得面目全非,那就重建。操作路径是:虚拟网络编辑器 → 更改设置 → 选中 VMnet8 → 点“还原默认设置”。

这个操作的实质是卸载并重装所有 VMware 虚拟网卡,然后恢复默认网络配置。执行完之后有三件事要注意:

第一,重启宿主机或者至少禁用再启用一次虚拟网卡,让系统重新识别。

第二,所有虚拟机的网络配置会回到 NAT 默认状态,之前设了静态 IP 的机器需要重新配。

第三,自定义的端口映射会丢失,如果有做外部访问的转发规则,得重新加。

我通常把这个操作放在最后,因为成本比较高。先按前几节走完,绝大多数问题能提前解决。

4. 桥接模式断网:九成问题出在网卡选择上

4.1 自动桥接为什么不可靠

桥接模式的故障率明显高于 NAT,原因只有一个:它要挑物理网卡。

虚拟机设置里桥接模式默认是“自动”,含义是让 VMware 自己判断该桥接到哪块物理网卡上。这台机器上有线网卡、无线网卡、甚至还有一堆虚拟网卡的时候,它的判断经常出错,可能桥接到一块根本没连网的网卡上。

处理方法很直接:在虚拟机的“设置 → 网络适配器”里,把模式选成“桥接”,然后勾选“复制物理网络连接状态”,再到虚拟网络编辑器里把 VMnet0 的桥接目标手动指定为你当前正在用的那块物理网卡。有线就选有线,无线就选无线,名字通常一眼能认出来。

这一步做完,桥接失败的问题能解决大半。

4.2 无线网卡桥接的特殊处理

无线网卡做桥接比有线麻烦。部分无线网卡驱动不支持混杂模式,虚拟机发出的帧带着自己的 MAC 地址,而无线接入点只认已经完成认证的那个 MAC,于是这些帧就被丢了,表现是虚拟机拿不到 IP,或者能拿到 IP 但网关不通。

几种处理思路:

  • 换成有线连接做桥接,这是最省事的办法,如果条件允许直接用。
  • 改用 NAT 模式,如果只是要上网,桥接本身没有必要性。
  • 在虚拟网络编辑器里切换桥接的物理网卡,有时候换个无线网卡(比如笔记本自带的那个和 USB 的)表现完全不同。
  • 检查无线网络是否开启了客户端隔离,公共网络里面很常见,即使桥接成功,虚拟机也访问不到局域网里的其他设备。

4.3 桥接后的IP规划与冲突排查

桥接模式下虚拟机用的是物理局域网的地址段,这就带来一个新问题:地址冲突。如果虚拟机里设了静态 IP,而这个 IP 恰好和局域网里某台设备撞了,表现就是两台机器轮流掉线,非常折磨人。

排查方法是:先让虚拟机用 DHCP 自动获取,确认能正常上网之后,再把拿到的地址固定下来。固定前在宿主机上执行一次arp -a看一下局域网里已经有哪些地址在用,避开它们。

现代路由器一般都有 DHCP 租约列表,登录路由器管理界面能直接看到哪些地址被分配出去了,比盲猜靠谱。没有管理权限的话,就选一个地址池末端不太可能被用到的地址,比如网段里的.200以上,冲突概率很低。

5. 仅主机模式与特殊场景的取舍

5.1 只想宿主机和虚拟机互通的正确配置

仅主机模式的配置极其简单:虚拟机网络适配器选“仅主机”,宿主机上对应的 VMnet1 网卡保持启用,两边配在同一网段即可。默认情况下 VMware 的虚拟 DHCP 会给虚拟机发地址,宿主机的 VMnet1 一般是网段里的.1。

验证方式就是宿主机 ping 虚拟机,虚拟机 ping 宿主机,能通就完事。这时候虚拟机访问外网是不通的,这是设计如此,不是故障。如果确实需要让虚拟机访问外网,那就不该用仅主机模式,直接换 NAT。

有个需求很常见:既想让虚拟机访问外网,又想让宿主机和虚拟机之间有一个固定不变的连接。做法是给虚拟机加第二块网卡,一块走 NAT 出网,一块走仅主机做宿主机互连。这样 IP 固定、断网也不影响本地调试。

5.2 双网卡组合:一个上网一个内网

多网卡配置的关键是默认路由只能有一条,否则会出现奇怪的断流。具体原则是:

  • 出网的那块网卡(NAT 或桥接)配置默认网关。
  • 内网的那块网卡(仅主机)只配 IP 和掩码,不配网关。

如果配了两条默认路由,系统会根据跃点值选一条,另一条流量就走不通,表现出来就是“有时候能上网有时候不行”。Windows 上用route print看,Linux 上用ip route show看,如果看到两条default记录,删掉内网的那条:

sudo ip route del default via 192.168.x.1 dev eth1

这个坑我在搭建本地测试集群的时候踩过,两台虚拟机互相能 ping 通,但都上不了网,最后发现是内网网卡抢了默认路由。

5.3 快照、克隆带来的MAC与网卡错乱

克隆虚拟机是另一个高频故障源。VMware 克隆时会问你是“创建完整克隆”还是“创建链接克隆”,不管哪种,MAC 地址必须重新生成。两台虚拟机 MAC 一样,接在同一个虚拟交换机上,交换机会直接懵掉,表现为两台机器都时通时不通。

虚拟机设置 → 网络适配器 → 高级 → 点“生成”按钮,重新生成一个 MAC。这一步花不了十秒钟,但能省掉几个小时的排查。

另外,从快照恢复之后也建议检查一下网卡状态。有些系统在快照恢复后会认为网卡是“新硬件”,重新枚举一遍,原来的网络配置就失效了,表现为网络图标带感叹号,重新配一次 IP 就好。

6. 客户机内部的分层排查手册

6.1 Windows客户机的四条命令

Windows 客户机排查,我固定跑这四条:

ipconfig /all # 看全部网络信息,包括 DHCP 服务器、DNS、MAC ipconfig /release # 释放当前租约 ipconfig /renew # 重新申请 nslookup www.example.com # 验证解析

ipconfig /all里重点看三项:有没有拿到 IPv4 地址、默认网关是不是虚拟网络的网关、DHCP 服务器地址是不是虚拟网络里的那个。如果 DHCP 服务器显示为空,说明请求压根没发出去或者没人应答,回到宿主机查服务。

网络栈被搞乱的情况下,用这两条命令重置:

netsh winsock reset netsh int ip reset

执行完必须重启才生效。这招对“本来好好的,装了个软件之后突然上不了网”这类问题特别管用,因为有些安全软件会往网络栈里插过滤驱动,卸载不干净就留下后遗症。

6.2 Linux客户机从网卡到DNS逐层确认

Linux 上我一般按这个顺序走:

ip link show # 网卡是不是 UP 状态 ip addr show # 有没有 IPv4 地址 ip route show # 默认路由在不在 cat /etc/resolv.conf # DNS 配置 ping -c 3 网关地址 ping -c 3 114.114.114.114 ping -c 3 www.example.com

ip link show如果显示state DOWN,先sudo ip link set eth0 up拉起来。如果显示NO-CARRIER,说明链路层没连上,问题在虚拟机的网络适配器设置,不是系统内部。

新版发行版大多用 NetworkManager 或 netplan 管理网络。用 netplan 的系统配置文件在/etc/netplan/下,改完要执行sudo netplan apply;用 NetworkManager 的直接nmcli就行:

nmcli connection show nmcli connection modify "有线连接 1" ipv4.method auto nmcli connection up "有线连接 1"

有个细节值得提:VMware Tools 影响网卡驱动。安装了 Tools 之后,虚拟网卡可能从e1000换成vmxnet3,性能更好,但如果 Tools 安装不完整或者版本不匹配,网卡可能直接认不出来。遇到ip link里压根没有以太网设备的情况,先在虚拟机设置里把网卡类型改成e1000试试,能认出来就说明是驱动兼容问题。

6.3 防火墙与安全软件的拦截识别

防火墙导致的“上不了网”有个典型特征:能 ping 通 IP,但某些端口连不上。比如能 ping 通 114.114.114.114,但浏览器打不开任何网页,因为 80/443 被拦了。

Windows 上临时关掉防火墙验证一下:

netsh advfirewall set allprofiles state off

验证完记得开回来。Linux 上:

sudo systemctl stop firewalld # CentOS 系 sudo ufw disable # Ubuntu 系

如果关了就好了,那就是规则问题,去防火墙里放行对应端口,而不是长期关着防火墙。

还有一种情况是宿主机上的安全软件拦截了虚拟网卡的流量。这类软件有时会把 VMware 的虚拟网卡识别成可疑设备,直接切断它的通信。判断方法是看它的拦截日志,或者在它的网络防护设置里把 VMnet1、VMnet8 加入信任列表。

7. 典型故障速查表与踩坑实录

7.1 症状到原因速查表

现象最可能的原因处理动作
虚拟机无 IP,显示 169.254 开头DHCP 服务未启动或虚拟网卡禁用启动 VMware DHCP Service,启用 VMnet8
有 IP,ping 网关不通IP 与虚拟网络不同网段检查虚拟网络编辑器网段设置
ping 网关通,ping 公网 IP 不通NAT 服务未启动启动 VMware NAT Service
ping 公网 IP 通,域名不通DNS 配置错误手动指定公共 DNS
桥接模式拿不到 IP桥接目标网卡选错手动指定物理网卡
桥接模式时通时不通物理网络存在 MAC 限制或地址冲突换 NAT 模式,或改用动态获取
克隆后两台机器抢网MAC 地址重复重新生成 MAC
虚拟网卡有黄色感叹号驱动损坏或与其他虚拟化组件冲突卸载重装虚拟网卡
装了某软件后突然断网网络栈被过滤驱动污染netsh winsock reset后重启
网络图标正常但浏览器打不开系统层拦截或路由异常检查防火墙与路由表

7.2 几个反直觉的坑

坑一:宿主机连着需要认证的网络。有些公共网络要先在浏览器里点同意才能上网,这时候宿主机自己都还没通,虚拟机当然上不去。有次在会议室折腾了半小时,最后发现是宿主机没点那个登录按钮。

坑二:系统时间不同步导致的“打不开网页”。部分站点对时间偏差很敏感,虚拟机关机放几天再开,时间落后一大截,访问会直接被拒。表现和网络故障极像,但ping全通。装个时间同步服务就能避免。

坑三:MTU 不匹配。虚拟网络默认 MTU 是 1500,而某些拨号链路实际是 1492,大包发不出去,小包正常。表现是能打开简单页面,图片多的页面一直转圈。验证方法是用不分片的包试探:

ping -f -l 1472 114.114.114.114

不通就逐步减小包长,找到能通过的最大值,然后相应调小网卡的 MTU。

坑四:虚拟机设置里“已连接”没勾。这个坑我每年都要撞上一次。虚拟机的网络适配器设置里有两个复选框,一个是“已连接”,一个是“启动时连接”。后者没勾,虚拟机重启后就断网;前者没勾,当时就断网。两个都得勾上。

坑五:开了某些虚拟化相关组件之后桥接失效。宿主机如果启用了系统自带的虚拟化平台功能,可能和 VMware 的桥接驱动打架,表现就是桥接死活不通,NAT 正常。这种情况要么关掉那个功能重启,要么干脆用 NAT。

7.3 兜底手段与我的日常习惯

配置改乱了又懒得一步步查,我直接按这个顺序兜底:先在虚拟网络编辑器里还原默认设置,重启宿主机的 VMware 相关服务,再开虚拟机跑一次 DHCP。三步下来九成问题能自愈。

日常使用上,我养成几个习惯,能省不少事:

  • 虚拟机一律先装 VMware Tools,网卡驱动、时间同步、剪贴板共享都靠它,装与不装差别很大。
  • 克隆完立刻改 MAC,别等出问题再回头找。
  • 给每台虚拟机记一笔网络用途,是 NAT 出网还是仅主机内网,写个备注在虚拟机名字后面,半年后回来看不至于懵。
  • 重要环境拍快照之前先确认网络是通的,免得回滚到一个断网状态自己还不知道。
  • 宿主机换了网络环境(换 Wi-Fi、插网线)之后,桥接模式要重新确认一次物理网卡,这是我遇到频率最高的一类“突然上不了网”。

虚拟机网络这块,说到底就那么几个变量:用哪种模式、桥到哪块网卡、虚拟网段配得对不对、客户机内部拿没拿到正确参数。把这四个问题按顺序问一遍,绝大多数断网都能在十分钟内定位。真正耗时间的从来不是技术难度,是排查顺序乱了、在错误的层面上反复尝试。

RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进