一、事故背景
昨晚虚拟机还好好的，今天下午准备在 VMware 中的 OpenKylin 系统里安装 Claude Code，刚登录进去发现：网络彻底断了。
任务栏右下角飘着刺眼的红字------维护模式。
快捷操作面板里网络显示"未连接"，有线网络设置里 ens33 网卡开关是灰的，点一下又弹回去。就此开始了长达数小时的排查之旅。
二、环境说明
| 项目 | 内容 |
|---|---|
| 宿主机 | Windows + VMware Workstation Pro 17 |
| 虚拟机系统 | OpenKylin（开放麒麟） |
| 网络模式 | NAT（VMnet8，子网 192.168.255.0） |
| 网卡名称 | ens33（别名 enp2s1） |
| 宿主机上网方式 | 手机热点 |
三、排查过程与失败记录
3.1 第一反应：重启 NetworkManager
sudo systemctl restart NetworkManager
nmcli device status结果： ens33 显示"未托管"（unmanaged），重启没有任何效果。
3.2 尝试手动连接
nmcli device connect ens33报错：
错误：添加/激活新连接失败：Connection 'ens33' is not available
on device ens33 because device is strictly unmanaged关键词：strictly unmanaged。这说明不是简单的断线，而是 NetworkManager 被明确配置为不管理这块网卡。
3.3 定位配置文件问题
cat /etc/NetworkManager/NetworkManager.conf输出中发现：
[ifupdown]
managed=false找到了！managed=false 导致 NetworkManager 拒绝接管任何通过 /etc/network/interfaces 管理的网卡。
尝试修复：
sudo sed -i 's/managed=false/managed=true/' /etc/NetworkManager/NetworkManager.conf
sudo systemctl restart NetworkManager结果： 依然 unmanaged，修改没有生效。
3.4 怀疑 conf.d 目录有覆盖配置
sudo grep -r "unmanaged\|managed=false" /etc/NetworkManager/结果： 无输出。配置文件里已经没有 unmanaged 相关设置了，但问题依旧。
说明 NetworkManager 在运行时缓存了旧配置，或者还有其他机制在起作用。
3.5 强制 reload 并重新托管
sudo nmcli general reload
sudo nmcli device set ens33 managed yes
nmcli device status结果： 仍然显示"未托管"。nmcli device set 命令在这个状态下无法持久化。
3.6 尝试退出维护模式
sudo systemctl default
sudo systemctl isolate graphical.target
systemctl get-default输出：
graphical.target系统默认目标已经是 graphical.target，理论上不在维护模式------但界面上依然显示"维护模式"红字。这说明"维护模式"是 OpenKylin 自己的界面提示，并不完全等同于 systemd 的 rescue/emergency target。
3.7 删除连接重建
由于终端无法输入中文，尝试：
sudo nmcli connection delete ens33报错：
错误：未知的连接 "ens33"
错误：无法删除未知连接：'ens33'连接配置文件已经不存在了，但网卡依然是 unmanaged 状态，陷入了死循环。
3.8 绕过 NetworkManager，手动配置 IP
既然 NetworkManager 不肯接管，直接用 ip 命令手动配置：
sudo ip link set ens33 up
sudo ip addr add 192.168.255.100/24 dev ens33
sudo ip route add default via 192.168.255.2
ping 8.8.8.8结果： 路由添加时报错 Nexthop has invalid gateway，ping 依然不通。
原因分析：ens33 状态为 DOWN，即使添加了 IP，网卡物理层没有 up，网关也无法到达。
四、根本原因深度分析
经过完整排查，总结出以下几个根本原因叠加导致了此次故障：
原因一：维护模式破坏了网络服务状态
OpenKylin 进入维护模式后，部分系统服务被强制停止。NetworkManager 虽然进程还在，但其对网卡的控制状态没有随着退出维护模式而恢复。这是 systemd 与 NetworkManager 之间的状态同步问题。
原因二：managed=false 的历史遗留
OpenKylin 基于 Ubuntu/Debian 体系，默认使用 ifupdown 插件管理网络。/etc/NetworkManager/NetworkManager.conf 中的 managed=false 是该体系的历史遗留配置------意思是"凡是在 /etc/network/interfaces 中定义的网卡，NetworkManager 不接管"。
这本是正常配置，但在维护模式破坏网络状态后，叠加这个配置，导致恢复网络的所有 nmcli 命令全部失效。
原因三：连接配置文件丢失
/etc/NetworkManager/system-connections/有线连接 1.nmconnection 文件在某个时刻（可能是维护模式中或之后的误操作）被删除或损坏，导致 nmcli 找不到可用的连接配置，无法激活。
原因四：网卡持续处于 DOWN 状态
2: ens33: <BROADCAST,MULTICAST> state DOWN网卡没有 UP，即使手动配置 IP 和路由，底层链路不通，所有网络操作都会失败。这是最底层的问题，应该最先解决。
五、正确的解决思路（复盘）
如果重来一次，正确的排查顺序应该是：
第一步：先把网卡 UP
sudo ip link set ens33 up第二步：修改 managed=false 为 true
sudo sed -i 's/managed=false/managed=true/' /etc/NetworkManager/NetworkManager.conf第三步：重新加载 NetworkManager
sudo systemctl restart NetworkManager
sudo nmcli general reload第四步：重建连接配置
sudo nmcli connection add type ethernet ifname ens33 con-name "eth0" ipv4.method auto
sudo nmcli connection up "eth0"第五步：验证
ip addr show ens33
ping 8.8.8.8六、经验教训
- 维护模式不要随便进：OpenKylin/Ubuntu 系维护模式会影响网络服务状态，退出后不会自动完全恢复。
- 排查网络问题要从底层开始 ：先检查网卡是否 UP（
ip link show），再检查 IP（ip addr），再检查路由（ip route），最后才是上层的 NetworkManager。 managed=false是陷阱：在 Debian 系系统中，这个配置会让 nmcli 的所有操作都失效，遇到 "strictly unmanaged" 报错第一时间去查这个配置。- nmcli 依赖连接配置文件 ：没有
.nmconnection文件，nmcli 无法激活连接，需要先connection add再connection up。 - 虚拟机网络故障优先检查宿主机：NAT 模式下，宿主机有网，虚拟机配置正确就能有网，不要在虚拟机里找手机热点。
七、总结
这次故障的核心是：维护模式 + managed=false + 连接配置丢失 + 网卡 DOWN 四个问题同时出现，每一个单独都好解决，叠加在一起让排查走了很多弯路。
希望这篇踩坑记录能帮到同样在 OpenKylin 或其他国产 Linux 系统上遇到类似问题的同学。