
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 的直接原因之一。临时修复手动激活接口并获取 IPsudoiplinksetens33 upsudodhclient ens33执行后成功通过 DHCP 获取到地址192.168.1.96/24IPv6 地址正常网络恢复连通外网连通性验证通过$ping-c3www.baidu.com3packets transmitted,3received,0% packet loss rtt min/avg/max/mdev13.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 面板」的根因方向。阶段 4NetworkManager unmanaged 深层排查围绕「谁把 ens33 标记成了 unmanaged」展开逐层排查排查项命令结果桌面环境确认echo $XDG_CURRENT_DESKTOPubuntu:GNOME应走 NetworkManager 方案netplan 渲染器cat /etc/netplan/*.yaml✅ 已是renderer: NetworkManager正常NM 主配置cat /etc/NetworkManager/NetworkManager.conf❌ 发现[ifupdown] managedfalse改为true旧式网络配置cat /etc/network/interfaces✅ 文件不存在无冲突NM 服务状态systemctl status NetworkManager✅enabledactive (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不匹配 ens33udev 设备属性udevadm info /sys/class/net/ens33✅ 无 NM_UNMANAGED 标记NM 日志journalctl -u NetworkManager -b | grep -i ens33NM 能识别设备、检测到链路连接但始终不接管、不创建连接也无任何 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→ 不报错但状态纹丝不动说明属于配置级/系统级 unmanageddevice 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 覆盖、managedtrue、device set均无法解除purge 重装 NetworkManager恢复出厂配置四、经验与最佳实践排错方法论由外到内逐层排查宿主机虚拟网络配置 → 虚拟机硬件层网卡识别→ 接口状态 → 网络管理服务每层用命令验证后再深入下一层重启验证是分水岭手动修复能联网但重启复发说明问题在「自动化管理组件」而非链路本身识别性价比拐点当配置、udev、日志三层排查均正常但行为反常时重置/重装的性价比已超过继续深挖应果断切换路线避免无限纠缠重装优先用purge普通remove会保留被改坏的配置文件purge才能彻底回归出厂状态VMware 网络模式选择建议场景推荐模式原因虚拟机只需上网下载、git clone、日常开发NAT不依赖宿主机具体物理网卡宿主机有线/Wi-Fi 切换无感局域网内其他设备需直连虚拟机如开发板连虚拟机的服务桥接虚拟机直接获得局域网 IP桥接目标必须选对真实物理网卡常用诊断命令速查iplink# 查看所有网络接口及状态UP/DOWNipaddr# 查看接口 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 面板。