资讯详情

Ubuntu Server 网络切换:从 netplan 无缝接管到 NetworkManager 全指南

📅 2026/10/11 0:44:22 | 华诺云谱 👁 阅读
Ubuntu Server 网络切换:从 netplan 无缝接管到 NetworkManager 全指南
简介针对Ubuntu Server 20.04默认采用netplan管理网络、而部分用户更习惯Network Manager灵活配置的情况这份PDF技术文档给出了完整的接管方案。内容面向Linux运维与服务器管理人员系统讲解如何安装network-manager、将NetworkManager.conf中managed改为true、调整netplan渲染器为NetworkManager并通过netplan apply与systemctl restart使配置生效。文档还整理了nmcli常用操作如查看设备状态、列出与激活连接便于后续进行DHCP、无线及有线网络的动态切换。资源共1个PDF文件压缩包约25KB内容精炼适合快速查阅也适合需要动态网络配置或希望摆脱纯命令行编辑配置的用户作为参照。目前已有5253人学习下载是服务器网络配置场景中一份实用的技术资料。1. 先搞清楚NetworkManager和netplan的分工为什么要接管Ubuntu Server 20.04 默认用netplan管理网络底层渲染器是systemd-networkd。很多人想换成NetworkManager结果直接在/etc/network/interfaces里改配置或者把managed改成true就以为完事了重启后SSH直接断。这篇要解决的是一个具体问题怎么把网络管理权从netplannetworkd切换到NetworkManager同时保证IP不丢、连接不断、配置可回滚。适合刚接触Ubuntu Server、被netplan的YAML语法折腾过、又需要用nmcli查Wi-Fi或做动态网络切换的从业者。读完你不仅能完成切换还能在翻车时自己把网络救回来。2. 安装与启用从netplan到NetworkManager的切换实录2.1 安装network-manager一条命令背后的依赖关系在干净的Ubuntu Server 20.04上默认没有安装network-manager这个包。直接在SSH会话里执行sudo apt update sudo apt install network-manager -y第一行命令刷新软件源索引避免系统拿着过期的包列表去解析依赖第二行的-y参数跳过交互确认防止安装过程卡在是否继续的提示上。安装时apt会自动带上依赖包包括libnm、ModemManager等这些是为Wi-Fi和移动宽带场景准备的体积不大不需要手动剔除。有个常见的疑问是装完network-manager之后要不要再装network-manager-cli实际上nmcli工具已经包含在network-manager包里了。装完建议用dpkg -l network-manager和nmcli --version确认版本Ubuntu Server 20.04官方源里对应的版本通常在1.22.10左右这个版本跟netplan的配合已经比较成熟。注意如果是在最小化安装或者裁剪过的容器镜像里操作可能缺少systemctl服务文件。安装完成后执行一次systemctl daemon-reload否则service列表里看不到network-manager后面restart会报错。安装完先别急着改配置看一眼服务当前状态执行systemctl status network-manager。如果显示inactive或者failed说明服务还没接管任何接口这正是动手改配置的最佳时机。如果是active状态也不用慌只要还没改netplanNetworkManager默认不会碰你已经配置好的网卡。2.2 修改NetworkManager.confmanaged参数到底管什么打开NetworkManager的主配置文件sudo vim /etc/NetworkManager/NetworkManager.conf默认内容如下[main] pluginsifupdown,keyfile [ifupdown] managedfalse需要把managed改成true[main] pluginsifupdown,keyfile [ifupdown] managedtrue这里要解释清楚managed参数的作用范围。它控制的是NetworkManager是否接管/etc/network/interfaces里定义的接口。在Ubuntu Server上interfaces文件通常是空的但NetworkManager默认依然不会去碰任何未被自己创建的接口。改成true之后NetworkManager会对所有内核可见的物理网卡进行管理包括之前在netplan里配置过的以太网口。有一个普遍存在的误区觉得managedtrue改完就万事大吉了。实际上这个参数只管ifupdown插件这一条路径而netplan生成的配置是走另一条路径交给NetworkManager的。所以下面的netplan配置修改一步都不能跳过两个文件是配合关系不是替代关系。另外注意[main]段里的plugins行如果看到除ifupdown、keyfile之外还有别的插件不要随手删掉。在纯服务器场景里保持默认就好多删一个插件可能导致NetworkManager无法识别已有连接后续nmcli connection show里什么都看不到。2.3 改netplan配置renderer切换的本质找到netplan配置文件通常叫01-netcfg.yaml或者类似的名字sudo vim /etc/netplan/01-netcfg.yaml切换前的内容大概长这样network: version: 2 renderer: networkd ethernets: ens33: dhcp4: true切换后只需要保留核心声明network: version: 2 renderer: NetworkManager关键在renderer字段。netplan本身不直接实现网络功能它只负责把YAML翻译成后台服务能读懂的配置。renderer改成NetworkManager之后netplan生成的配置会落到/etc/NetworkManager/system-connections/目录以keyfile格式存在而不是之前的systemd-networkd配置文件。有个细节容易被忽略如果YAML里保留着ethernets段netplan依然会为那块网卡生成一份连接配置。这在多数情况下不会出问题但如果你希望后续完全由nmcli接管IP、DHCP、DNS的设置更干净的做法是只留renderer行把ethernets段注释或删掉。否则每次netplan apply都可能用旧地址覆盖掉你用nmcli做的修改形成配置打架。改完先做语法预检不要直接applysudo netplan generate sudo netplan try --timeout30netplan try会让新配置在30秒内生效如果这期间没有收到确认自动回滚到上一个可用配置。这是防止SSH断连最有效的一招。确认输出显示配置正常后再执行apply顺序问题下一章展开。3. 应用与验证netplan apply之后发生了什么3.1 应用配置的正确顺序网上很多教程的顺序是乱的有人先重启network-manager再netplan apply结果网卡直接消失。我实际操作下来正确的顺序是sudo netplan apply sudo systemctl restart network-manager如果前面已经用netplan try确认过配置无误这里直接执行apply即可。netplan apply的作用是重新读取YAML、生成底层配置并触发应用。当renderer是NetworkManager时netplan会把新的keyfile写入system-connections目录然后通知NetworkManager重新加载连接。但netplan的通知机制有时候不可靠尤其是刚从networkd切到NetworkManager的第一个配置周期服务可能没监听到文件变化。所以紧接着重启network-manager服务强制所有接口按新配置重新走一遍接管逻辑这样状态才稳定。反过来执行会碰到什么情况NetworkManager先启动发现设备还没被释放于是标记为unmanaged等netplan apply之后设备的归属已经乱了需要nmcli device reapply手动救回来。顺序问题不是玄学是两个服务加载时序的真实差异。3.2 用nmcli验证接管是否成功配置应用完后第一件事是看设备状态nmcli device status输出是一个表格重点看STATE列。如果显示connected说明网卡已经被NetworkManager正常管理。如果显示unmanaged或者disconnected说明接管没有完成回到第2章检查managed参数和renderer配置。接着看连接配置nmcli connection show切换成功后这里会出现类似Wired connection 1的连接条目。后面做静态IP、DHCP修改时引用的就是这个NAME字段注意不是网卡名ens33之类的DEVICE字段这两个概念在nmcli里完全不同搞混了会报unknown connection。3.3 网卡状态和路由的完整验证用传统命令确认实际效果ip addr show ip route show对比切换前后的输出确认IP地址、子网掩码、默认网关没有丢失。特别是默认路由如果default via那行不见了说明NetworkManager没有正常应用网关配置需要回过去检查连接配置里的ipv4.gateway字段。DNS验证容易被漏掉。Ubuntu Server上netplan阶段用的DNS是交给systemd-resolved处理的切换后NetworkManager会自动往resolved写入配置。用resolvectl status看一下当前DNS如果还是旧地址执行systemctl restart systemd-resolved再查一次。验证项命令预期结果设备状态nmcli device statusSTATE为connected连接列表nmcli connection show出现Wired connection条目IP地址ip addr show地址和掩码正确默认路由ip route show有default via行DNSresolvectl statusDNS地址正确这张表可以作为切换完成后的验收清单每一行都过一遍再继续往下操作。4. 用nmcli管理连接静态IP和DHCP的配置案例4.1 查看现有连接和设备对应关系接管成功之后日常管理基本都围着nmcli转。先看清楚当前的连接和设备关系nmcli connection show --active nmcli -f NAME,DEVICE,TYPE connection show-f参数用来指定输出字段NAME是连接配置的名字DEVICE是实际绑定的网卡TYPE是连接类型ethernet、wifi等。修改连接时用的是NAME不是DEVICE名。很多人在这一步把ens33当成连接名去执行nmcli connection up ens33结果直接报错因为ens33是设备名不是连接名。如果系统里有多个连接配置可以用nmcli connection show --active只看当前活跃的那几个。调整网络前先确认自己在改哪个连接这个习惯能省掉大半的配置错乱问题。4.2 配置静态IP的完整命令假设连接名叫Wired connection 1要配成静态IP执行sudo nmcli connection modify Wired connection 1 \ ipv4.method manual \ ipv4.addresses 192.168.1.50/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns 223.5.5.5 8.8.8.8逐项说明参数含义ipv4.method manual表示关闭DHCP、启用静态配置ipv4.addresses里192.168.1.50是IP地址/24是子网掩码这个前缀不能省略否则NetworkManager不知道网段范围ipv4.gateway是默认网关地址必须跟IP在同一个网段内ipv4.dns可以填多个DNS用空格分隔整体加引号防止shell拆成多个参数。执行完这条命令后配置只是写进了keyfile文件还没有真正下发到网卡。需要激活连接使配置生效sudo nmcli connection up Wired connection 1如果执行后IP没立刻变化先检查连接是否处于活跃状态。nmcli modify在连接活跃时支持热更新但某些场景下需要先down再up比如改了网卡的MAC地址或者VLAN设置。遇到IP不生效的情况最直接的办法是sudo nmcli connection down Wired connection 1 sudo nmcli connection up Wired connection 14.3 DHCP和DNS切换的实操切回DHCP比配静态简单sudo nmcli connection modify Wired connection 1 ipv4.method auto sudo nmcli connection up Wired connection 1ipv4.method auto表示使用DHCP获取地址同时之前手动设置的ipv4.gateway和ipv4.dns会被清空因为DHCP服务器会下发这些信息。如果你不想让DHCP下发的DNS覆盖本地配置再加一行参数sudo nmcli connection modify Wired connection 1 ipv4.ignore-auto-dns true这个参数在混合网络环境里很有用。比如公司内网DHCP下发的DNS解析不了外网域名但静态配置里又指定了公共DNS设成true之后NetworkManager会优先使用手动配置的DNS忽略DHCP下发的DNS。反过来想恢复默认行为把true改成false即可。5. 接管过程的常见问题与避坑排查5.1 问题网卡显示unmanagedIP地址全没了现象执行nmcli device status状态列显示unmanagedip addr里网卡上没有任何地址。原因最常见的是两个配置文件只改了一个。要么netplan里的renderer还是networkd要么NetworkManager.conf里的managed还是false。这两处是配合关系缺一个NetworkManager都不碰那块网卡。解决按顺序排查。先看/etc/netplan/*.yaml里renderer是不是NetworkManager再看/etc/NetworkManager/NetworkManager.conf里managed是不是true。确认无误后执行netplan apply再systemctl restart network-manager。注意是先apply再重启服务顺序反了可能出现unmanaged残留。5.2 问题SSH断开后连不上服务器失联现象远程修改网络配置执行netplan apply之后当前SSH会话立刻掉线之后ping不通这台机器。原因这个场景通常不是NetworkManager本身的问题而是新配置里IP地址变了或者网关配错导致网络不可达。很多人图省事直接netplan apply跳过了netplan try的30秒确认期配置错误时没有自动回滚的机会。解决如果机器有IPMI或物理控制台登录进去用ip addr看当前地址。网卡有地址但路由不对用nmcli connection modify改网关别急着改整个YAML。没有带外控制台的话只能安排现场处理这也是我反复强调用netplan try的原因。预防所有涉及远程网络的变更先netplan try --timeout30试一遍确认不会断连再apply。timeout可以按需加大到60秒给足确认时间。5.3 问题IP地址反复跳变重启后跟设置的不一样现象静态IP配置好后过一段时间变成DHCP分配的地址或者重启后IP不是自己在nmcli里设置的值。原因netplan的YAML里既有renderer行又有ethernets段netplan每次generate都会生成一份keyfile配置文件把你用nmcli做的修改覆盖掉。两个配置来源作用于同一块网卡时后执行的会赢表现就是IP来回跳。解决切换完成后把netplan的ethernets段彻底删掉只留最小化的renderer声明。之后的IP、DHCP、DNS全部交给nmcli管不要混用两种配置来源。如果已经出现覆盖重新用nmcli connection modify设置一遍然后nmcli connection up激活。5.4 问题NetworkManager服务启动失败日志报keyfile解析错误现象systemctl status network-manager显示active (failed)日志里出现无法打开或解析某个连接配置文件的记录。原因多半是手动编辑过/etc/NetworkManager/system-connections/目录下的文件YAML格式或者INI格式写错了或者文件权限不对。NetworkManager对这个目录权限要求严格连接文件的owner必须是root权限位不能开放给其他用户读写。解决先看具体是哪个文件报错sudo nmcli connection show报错的连接不会出现在列表里。把出问题的文件删掉或者修复权限sudo chmod 600 /etc/NetworkManager/system-connections/* sudo systemctl restart network-manager如果是格式问题用nmcli connection reload让NetworkManager重新读取配置比重启服务快也不会中断当前活跃的连接。6. 让NetworkManager接管更顺滑备份与验证的技巧6.1 把关键配置沉淀成文件不靠记忆nmcli命令式的修改是一次性的适合临时调整。想沉淀配置可以把连接导出sudo nmcli connection show Wired connection 1 /root/network-backup/conn.txt sudo cp -r /etc/NetworkManager/system-connections/ /root/network-backup/system-connections目录里的keyfile可以看到完整的IP、DNS、权限位设置。备份这个目录等于给网络配置吃了颗后悔药后续在哪台机器上复现同样配置直接把文件拷过去、改一下网卡名、重启服务就行。6.2 切换前记录基线回滚只用两步动手之前把当前网络配置完整记下来mkdir -p /root/network-backup cp /etc/netplan/*.yaml /root/network-backup/ ip addr /root/network-backup/ip-addr-before.txt ip route /root/network-backup/ip-route-before.txt回滚时只需要把备份的YAML拷回去把renderer改回networkd执行netplan apply重启一次网卡即可。这套基线记录在切换后第二天验证仍然有用能快速对比出配置漂移。我第一次在机房远程切换时就是直接netplan apply翻的车那台机器没有带外管理最后只能安排人现场接显示器处理。从那以后我每次改服务器网络配置都强制先走一遍netplan try加备份这套流程确认无误才动手。NetworkManager接管本身不复杂坑全在操作顺序和配置来源上先验证再执行希望帮到你。本文还有配套的精品资源点击获取
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。

↑