VMware 虚拟机中 Ubuntu 20.04 网络连接异常排查修复全记录-港品优选

VMware 虚拟机中 Ubuntu 20.04 网络连接异常排查修复全记录

环境：Windows 宿主机 + VMware Workstation + Ubuntu 20.04 桌面版虚拟机
故障现象：在宿主机重置 VM 网络适配器配置后，虚拟机中的 Ubuntu 20.04 仍无法正常联网
最终结果：完全修复，开机自动联网，GNOME 设置中 Wired 面板恢复

一、故障背景与现象

在宿主环境重置了 VM 的网络适配器配置后，虚拟机中的 Ubuntu 20.04 依然无法连接网络，表现为：

Ubuntu 系统设置的 Network 页面中完全没有 Wired（有线）选项，只剩 VPN 和 Network Proxy
虚拟机无法访问任何网络资源

二、排查与修复全过程

本次故障最终确认是三层问题叠加，排查过程按「由外到内、逐层深入」的顺序推进。

阶段 1：宿主机 VMware 桥接配置错误

发现的问题：打开 VMware「虚拟网络编辑器」，发现 VMnet0（桥接模式）的「已桥接至」绑定到了Microsoft Wi-Fi Direct Virtual Adapter——这是 Windows 的虚拟热点适配器，并非真实的物理网卡，桥接到它上面虚拟机必然无法联网。

修复措施：将「已桥接至」改为宿主机真实在用的物理网卡。本机使用有线上网，故选择Realtek PCIe GbE Family Controller（有线网卡）：

宿主机用 Wi-Fi 上网 → 应选无线网卡（如Realtek 8822CE Wireless LAN 802.11ac PCI-E NIC）
宿主机插网线上网 → 应选有线网卡（Realtek PCIe GbE Family Controller）
不建议选「自动」，自动桥接在存在 Wi-Fi Direct 虚拟适配器时容易选错

同时确认虚拟机设置中的网络适配器：桥接模式、勾选「已连接」「启动时连接」「复制物理网络连接状态」。

结论：宿主机侧配置修正完毕，但虚拟机内仍无网络 → 问题不止一层，继续向内排查。

阶段 2：虚拟机内网卡识别状态检查

在 Ubuntu 终端执行：

iplink

输出显示：网卡ens33已被系统识别（MAC 为 VMware 的00:50:56:3f:52:88），但接口状态为DOWN——接口没有被激活，自然拿不到 IP，这也是 GNOME 设置里没有 Wired 的直接原因之一。

临时修复（手动激活接口并获取 IP）：

sudoiplinksetens33 upsudodhclient ens33

执行后成功通过 DHCP 获取到地址192.168.1.96/24，IPv6 地址正常，网络恢复连通：

外网连通性验证通过：

$ping-c3www.baidu.com3packets transmitted,3received,0% packet loss rtt min/avg/max/mdev=13.173/13.915/14.703/0.625 ms

阶段 3：重启后故障复现 —— 发现 NetworkManager 未接管网卡

重启虚拟机后，ens33 再次回到 DOWN 状态，说明手动激活只是临时的，系统里没有组件负责在开机时配置网络。

检查 NetworkManager 的设备管理状态：

$ nmcli device status DEVICE TYPE STATE CONNECTION ens33 ethernet unmanaged -- lo loopback unmanaged --

关键发现：ens33处于unmanaged状态——NetworkManager 放弃了对这块网卡的管理。这就是「重启后必掉线 + GNOME 无 Wired 面板」的根因方向。

阶段 4：NetworkManager unmanaged 深层排查

围绕「谁把 ens33 标记成了 unmanaged」展开逐层排查：

排查项	命令	结果
桌面环境确认	`echo $XDG_CURRENT_DESKTOP`	`ubuntu:GNOME`，应走 NetworkManager 方案
netplan 渲染器	`cat /etc/netplan/*.yaml`	✅ 已是`renderer: NetworkManager`，正常
NM 主配置	`cat /etc/NetworkManager/NetworkManager.conf`	❌ 发现`[ifupdown] managed=false`，改为`true`
旧式网络配置	`cat /etc/network/interfaces`	✅ 文件不存在，无冲突
NM 服务状态	`systemctl status NetworkManager`	✅`enabled`+`active (running)`，正常
conf.d 覆盖配置	`grep -ri "unmanaged" /usr/lib/NetworkManager/conf.d/`	❌发现可疑文件（见下）
udev 规则	`grep -ri "NM_UNMANAGED" /etc/udev/rules.d/ /usr/lib/udev/rules.d/`	✅ 仅标准规则（vboxnet/vmnet/veth），不匹配 ens33
udev 设备属性	`udevadm info /sys/class/net/ens33`	✅ 无 NM_UNMANAGED 标记
NM 日志	`journalctl -u NetworkManager -b \| grep -i ens33`	NM 能识别设备、检测到链路连接，但始终不接管、不创建连接，也无任何 unmanaged 原因记录

其中最重要的发现是/usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf的内容：

[keyfile] unmanaged-devices=*,except:type:wifi,except:type:gsm,except:type:cdma

该配置的含义是：除 Wi-Fi/GSM/CDMA 外，其他所有设备一律不管理——有线网卡（ethernet）不在豁免名单中。

尝试过的修复：

在/etc/NetworkManager/conf.d/创建同名覆盖文件，为 ethernet 增加豁免：
```
[keyfile] unmanaged-devices=*,except:type:wifi,except:type:gsm,except:type:cdma,except:type:ethernet
```
→ 重启 NM 后无效
直接修改/usr/lib下的原文件 → 无效
sudo NetworkManager --print-config确认合并后的生效配置中 ethernet已被豁免，但nmcli device status依然显示 unmanaged
开启 DEBUG 日志级别重启 NM 抓取日志 → NM 能看到设备、检测到载波（carrier: link connected），但没有任何关于 unmanaged 原因的记录
sudo nmcli device set ens33 managed yes→ 不报错，但状态纹丝不动（说明属于配置级/系统级 unmanaged，device set只能解除用户级标记）

阶段性结论：NM 配置层、udev 层、日志层均正常，但行为反常——说明系统中存在排查视野之外的改动（该虚拟机曾安装过各类开发工具链，配置来历已不可考）。继续深挖的性价比已低于直接重置。

阶段 5：插曲 —— 宿主机切换 Wi-Fi 后再次断网

排查期间宿主机从有线切换到 Wi-Fi，虚拟机再次断网。这是桥接模式的固有特性：桥接绑定在具体物理网卡上，宿主机换网即失效。

解决方案：虚拟机网络适配器改用NAT 模式（走 VMnet8，由 VMware 做地址转换），宿主机无论用有线还是 Wi-Fi，虚拟机都能自动适配联网。

⚠️ 一个排错小坑：NAT 模式下用ifconfig查看只有lo，一度以为网卡丢失。实际上ifconfig默认只显示 UP 状态的接口，接口仍处于 DOWN 时被隐藏了，应使用ifconfig -a或ip link查看全部接口。

手动拉起接口验证 NAT 模式联网正常后，确认问题核心仍然是 NetworkManager 不接管网卡。

阶段 6：终局修复 —— 重装 NetworkManager 恢复出厂配置

鉴于深层排查无果，最终采用「核武器」方案：彻底重装 NetworkManager，将所有配置重置为 Ubuntu 桌面版出厂默认。

操作步骤：

# 1. 先手动恢复网络（重装过程需要联网下载软件包）sudoiplinksetens33 upsudodhclient ens33# 2. 彻底卸载（purge 会删除所有被改动过的配置文件）sudoaptpurge network-manager network-manager-gnome-y# 3. 清理排查期间添加的覆盖文件，避免残留sudorm-f/etc/NetworkManager/conf.d/10-globally-managed-devices.conf# 4. 重新安装sudoaptinstallnetwork-manager network-manager-gnome-y# 5. 重启虚拟机sudoreboot

重装前确认了 APT 软件源配置正常（阿里云镜像，focal-proposed未启用——这是正确的，proposed 为未稳定测试源，不应开启）。

修复结果：重启后 NetworkManager 自动管理 ens33，创建默认连接「Wired connection 1」并通过 DHCP 获取地址，GNOME 设置中 Wired 面板恢复，显示Connected - 1000 Mb/s。

终验：

nmcli device status# ens33 ethernet connected Wired connection 1ping-c3baidu.com# 连通正常

三、根因分析总结

本次故障为三层问题叠加，缺一不可解：

层级	问题	修复方式
宿主机层	VMnet0 桥接绑定到 Microsoft Wi-Fi Direct 虚拟适配器（非物理网卡）	虚拟网络编辑器中改绑真实物理网卡
虚拟机网络层	ens33 接口 DOWN，无组件负责激活	根本解决依赖下一层修复
系统服务层	NetworkManager 因来历不明的配置改动将 ens33 标记为 unmanaged，且常规手段（conf.d 覆盖、managed=true、device set）均无法解除	purge 重装 NetworkManager，恢复出厂配置

四、经验与最佳实践

排错方法论

由外到内逐层排查：宿主机虚拟网络配置 → 虚拟机硬件层（网卡识别）→ 接口状态 → 网络管理服务，每层用命令验证后再深入下一层
重启验证是分水岭：手动修复能联网但重启复发，说明问题在「自动化管理组件」而非链路本身
识别性价比拐点：当配置、udev、日志三层排查均正常但行为反常时，重置/重装的性价比已超过继续深挖，应果断切换路线，避免无限纠缠
重装优先用purge：普通remove会保留被改坏的配置文件，purge才能彻底回归出厂状态

VMware 网络模式选择建议

场景	推荐模式	原因
虚拟机只需上网（下载、git clone、日常开发）	NAT	不依赖宿主机具体物理网卡，宿主机有线/Wi-Fi 切换无感
局域网内其他设备需直连虚拟机（如开发板连虚拟机的服务）	桥接	虚拟机直接获得局域网 IP；桥接目标必须选对真实物理网卡

常用诊断命令速查

iplink# 查看所有网络接口及状态（UP/DOWN）ipaddr# 查看接口 IP 地址ifconfig-a# 注意：不加 -a 只显示 UP 的接口nmcli device status# NetworkManager 设备管理状态nmcli general status# NM 总体状态systemctl status NetworkManager# NM 服务状态sudoNetworkManager --print-config# 查看 NM 合并后的生效配置journalctl-uNetworkManager-b# 查看本次启动的 NM 日志sudoiplinksetens33 up# 手动激活接口（临时）sudodhclient ens33# 手动 DHCP 获取地址（临时）

关键配置参考

netplan 交由 NetworkManager 管理（桌面版默认）：

# /etc/netplan/01-network-manager-all.yamlnetwork:version:2renderer:NetworkManager

备选方案：绕过 NetworkManager，由 systemd-networkd 直接管理（适合不需要图形化网络面板的场景）：
```
network:version:2renderer:networkdethernets:ens33:dhcp4:true
```
执行sudo netplan apply生效，开机自动联网，代价是 GNOME 设置中不显示 Wired 面板。

企业官网建设流程全解析