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 终端执行：

bash 复制代码

ip link

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

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

bash 复制代码

sudo ip link set ens33 up
sudo dhclient ens33

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

外网连通性验证通过：

bash 复制代码

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

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

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

检查 NetworkManager 的设备管理状态：

bash 复制代码

$ 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`

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

ini 复制代码

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

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

尝试过的修复：

在 /etc/NetworkManager/conf.d/ 创建同名覆盖文件，为 ethernet 增加豁免：
ini 复制代码
```
[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 桌面版出厂默认。

操作步骤：

bash 复制代码

# 1. 先手动恢复网络（重装过程需要联网下载软件包）
sudo ip link set ens33 up
sudo dhclient ens33

# 2. 彻底卸载（purge 会删除所有被改动过的配置文件）
sudo apt purge network-manager network-manager-gnome -y

# 3. 清理排查期间添加的覆盖文件，避免残留
sudo rm -f /etc/NetworkManager/conf.d/10-globally-managed-devices.conf

# 4. 重新安装
sudo apt install network-manager network-manager-gnome -y

# 5. 重启虚拟机
sudo reboot

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

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

终验：

bash 复制代码

nmcli device status    # ens33  ethernet  connected  Wired connection 1
ping -c 3 baidu.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；桥接目标必须选对真实物理网卡

常用诊断命令速查

bash 复制代码

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

关键配置参考

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

yaml 复制代码

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

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