1. 从ifupdown到Netplan为什么Ubuntu的网络配置方式变了如果你是从Ubuntu 16.04或更早版本一路用过来的老用户最近几年在配置服务器或桌面版的网络时可能会感到一丝困惑。那个熟悉的/etc/network/interfaces文件似乎不那么管用了取而代之的是一个名为/etc/netplan/的目录和里面那些以.yaml结尾的配置文件。这个变化始于Ubuntu 17.10并在后续的18.04 LTS及所有更高版本包括最新的22.04 LTS、24.04 LTS中成为默认的网络配置方式。这个新的工具就是Netplan。Netplan的出现并非是为了增加配置的复杂度而是为了解决一个长期存在的历史遗留问题Linux世界网络配置工具的碎片化。在传统的Linux系统中网络接口的启动、停止和配置底层依赖于各种不同的“渲染器”比如古老的ifupdown脚本、systemd-networkd或者NetworkManager。用户往往需要在不同的工具和配置文件格式之间切换体验割裂。Netplan的定位是一个网络配置抽象层。它允许用户使用统一的、人类可读性更强的YAML格式在一个地方/etc/netplan/定义好所有网络接口的配置。然后Netplan会根据你的系统环境将这些高级配置“翻译”渲染成底层渲染器如systemd-networkd或NetworkManager能够识别的原生配置文件。对于服务器环境Netplan默认使用systemd-networkd作为后端渲染器因为它轻量、高效且与systemd深度集成非常适合无图形界面的场景。对于桌面环境它则可能使用NetworkManager以更好地支持图形化网络管理小程序。这种设计带来了几个实实在在的好处首先是配置的一致性无论底层是哪个渲染器你只需要学习Netplan这一套语法其次是声明式配置你只需要描述网络“应该是什么状态”而不是写一堆命令去“如何达到这个状态”这让配置更清晰也更容易纳入版本管理如Git最后是与云和自动化工具的天然亲和性YAML格式正是像Ansible、Cloud-Init这类自动化工具所青睐的这使得在大量服务器上批量部署和变更网络配置变得非常高效。所以当你面对一台高版本Ubuntu18.04时忘记/etc/network/interfaces吧Netplan才是你现在需要掌握的核心工具。它并不难只是换了一种更现代、更强大的表达方式。接下来我将带你从零开始彻底搞懂如何用Netplan设置静态IP和动态IP并分享一些只有踩过坑才知道的实战经验。2. 初识Netplan配置文件结构与核心语法解析在开始动手修改配置之前我们必须先理解Netplan配置文件的“游戏规则”。所有Netplan的配置文件都存放在/etc/netplan/目录下。当你第一次查看这个目录时可能会看到类似00-installer-config.yaml、01-netcfg.yaml这样的文件。它们的名字本身没有特殊含义Netplan会按字母数字顺序读取该目录下所有的.yaml文件并合并处理。通常我们只需编辑或创建一个文件即可。一个最基本的Netplan YAML文件结构如下所示network: version: 2 renderer: networkd # 或 NetworkManager ethernets: enp3s0: dhcp4: true我们来逐行拆解这个“麻雀虽小五脏俱全”的配置network:这是整个Netplan配置的根节点所有内容都缩进在它之下。version: 2必须声明。这表示我们使用的是Netplan当前支持的配置语法版本version 2。请务必写上这一行。renderer:指定使用的后端渲染器。对于服务器通常设为networkd即systemd-networkd对于桌面版如果想用图形化工具管理可以设为NetworkManager。如果省略Netplan会根据系统环境自动选择。ethernets:这是一个“设备类型”节点用于配置有线以太网接口。类似的还有wifis:用于无线网卡和bridges:、bonds:等用于高级网络功能。enp3s0:这是网络接口的名称。这是你需要确认的第一个关键信息。你可以通过命令ip link show或ls /sys/class/net来查看你系统上的实际接口名。常见的命名规则有eth0传统、enp3s0PCIe位置命名、ens33VMware虚拟机常见等。请务必使用你自己系统上的真实接口名。dhcp4: true这是一个针对enp3s0接口的配置项表示通过DHCPv4协议自动获取IP地址即动态IP。对应的dhcp6: true用于DHCPv6。YAML语法非常注重缩进通常使用两个空格作为一个缩进层级。错误的缩进会导致Netplan无法正确解析文件。另外冒号:后面的值如果是字符串如接口名通常不需要引号但如果是布尔值true/false或数字则直接书写。注意在修改任何配置文件之前强烈建议先备份原始文件。例如sudo cp /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml.backup。这是一个能让你在配置出错时快速回滚的好习惯。3. 实战配置一为服务器设置静态IP地址在服务器环境中静态IP是标配它确保了服务的可达性和稳定性。假设我们的服务器有线网卡名称为ens33在VMware虚拟机中很常见我们希望为其设置一个固定的IP地址192.168.1.100/24网关是192.168.1.1DNS服务器使用8.8.8.8和8.8.4.4。我们需要编辑或创建/etc/netplan目录下的一个yaml文件。这里我创建一个新的配置文件以便清晰管理sudo nano /etc/netplan/01-static-ip.yaml将以下配置内容粘贴进去network: version: 2 renderer: networkd ethernets: ens33: addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: [8.8.8.8, 8.8.4.4] dhcp4: no dhcp6: no现在我们来详细解释每一个配置项的作用和背后的逻辑addresses:这是一个列表项以-开头用于指定一个或多个静态IP地址。192.168.1.100/24是CIDR表示法/24等同于子网掩码255.255.255.0。这里的关键是Netplan要求你必须带上子网前缀长度即/24而不能像旧配置里只写IP和独立的子网掩码。routes:用于配置路由表。- to: default是一个特殊的目标它表示“默认路由”即所有目标地址不匹配其他更具体路由的数据包都将通过这条路由发出。via: 192.168.1.1指定了到达这个“默认”目标的下一跳网关地址。在大多数局域网设置中配置默认路由就足够了。如果你有复杂的多网卡、多网关需求可以在这里定义更多具体的路由条目。nameservers:用于配置DNS解析。addresses:后面是一个YAML列表用方括号[]括起来逗号分隔列出了DNS服务器的IP地址。你可以根据需要添加多个。这里我使用了Google的公共DNS。对于内网环境你通常需要换成公司或家庭路由器的DNS如192.168.1.1。dhcp4: no和dhcp6: no这一点至关重要。当你明确设置了静态地址addresses后必须显式地将dhcp4和dhcp6设置为no或false。否则Netplan可能会尝试同时应用DHCP和静态配置导致网络接口行为异常或无法启动。配置保存后不要立即重启网络服务或系统。Netplan提供了一个非常强大的试运行和验证命令sudo netplan try这个命令会应用新的配置并等待120秒。在这期间你的SSH连接如果正在使用会保持。你可以快速测试新的网络配置是否工作例如ping一下网关或外网。如果网络正常按回车确认更改新配置将永久生效。如果网络中断比如你配错了网关120秒后配置会自动回滚到之前的状态你的SSH连接也不会丢失。这是一个极其安全的测试方式。如果你确认配置无误或者想直接应用可以使用sudo netplan apply这个命令会立即应用配置并生效。应用后使用ip addr show ens33和ip route show命令来验证IP地址和路由是否正确配置。再用nslookup example.com或ping -c 4 8.8.8.8来测试DNS和网络连通性。4. 实战配置二配置动态IPDHCP与多网卡场景动态IP配置相对简单适用于大多数桌面环境或服务器中无需固定地址的网卡。继续使用ens33为例启用DHCPv4的配置如下network: version: 2 renderer: networkd # 桌面版可改为 NetworkManager ethernets: ens33: dhcp4: true dhcp6: false # 根据需求开启或关闭IPv6 DHCP是的就是这么简单。将dhcp4设为trueNetplan就会在启动该接口时通过DHCP请求获取IP、网关、DNS等所有信息。如果你不需要IPv6可以将dhcp6设为false。在实际工作中我们经常会遇到服务器配备多个网络接口的情况。例如一个接口ens33连接业务网络静态IP另一个接口ens34连接管理网络或备份网络动态IP或另一个网段的静态IP。Netplan可以非常优雅地在同一个配置文件中管理它们network: version: 2 renderer: networkd ethernets: ens33: addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: [8.8.8.8, 192.168.1.1] dhcp4: no ens34: dhcp4: true # 可选为第二个接口设置不同的路由表或策略路由这里先保持简单DHCP在这个配置中我们同时定义了ens33和ens34两个接口。Netplan会并行处理它们。应用配置后两个接口会各自按照设定工作。你可以通过ip addr show查看所有接口的状态来验证。实操心得多网卡路由陷阱当系统存在多个接口且都配置了网关尤其是都通过DHCP获取了默认网关时可能会引起路由冲突导致网络流量从非预期的接口流出。这是多网卡配置中的一个经典坑。为了避免这个问题对于非主出口的网卡我们通常有两种做法不配置默认网关在静态配置中只为出口网卡设置routes:里的to: default。对于DHCP获取的网卡如果可能在DHCP服务器端配置不要下发默认网关选项。使用策略路由这是更高级和精确的控制方式。Netplan支持通过routing-policy:节点来配置基于源地址的路由规则可以确保来自某个网段或IP的流量从指定的接口出去。这需要更复杂的配置但对于生产环境的多宿主服务器是必要的。5. 深度排查Netplan配置不生效的常见原因与解决思路即使按照教程一步步操作有时应用netplan apply后网络依然没反应或者直接报错。别慌这是学习和排查问题的最佳时机。下面我梳理了一套完整的排查链路你可以像侦探一样一步步缩小范围。第一步检查YAML语法和缩进这是最常见的问题。YAML对格式极其敏感。使用以下命令检查语法sudo netplan generate如果这个命令没有任何输出或者只输出一些debug信息通常说明语法没问题。如果报错它会明确指出哪一行、哪个位置有问题比如“mapping values are not allowed in this context”往往意味着缩进错误。一个快速检查缩进的方法是使用cat -A命令它会把制表符显示为^I把行尾显示为$确保你使用的是空格而不是Tab。第二步验证渲染器后端服务状态Netplan只是一个配置生成器最终干活的是systemd-networkd或NetworkManager。你需要确保对应的服务是活跃的。如果你配置中指定或默认使用networkdsudo systemctl status systemd-networkd查看状态是否为active (running)。如果不是使用sudo systemctl start systemd-networkd启动并用sudo systemctl enable systemd-networkd设置开机自启。如果你使用NetworkManager桌面版常见sudo systemctl status NetworkManager同样确保其运行。对于服务器通常不建议混用两个渲染器保持一致性。第三步查看底层渲染器生成的最终配置Netplan的配置只是一个“蓝图”它会生成底层渲染器能读懂的配置。查看这些最终文件能帮你确认Netplan的“翻译”是否正确。对于systemd-networkd生成的配置文件通常在/run/systemd/network/或/etc/systemd/network/下。可以查看sudo cat /run/systemd/network/10-netplan-ens33.network这个文件的内容应该反映了你在Netplan YAML中的配置IP、网关、DNS等。如果这里的内容不对说明Netplan生成环节有问题。对于NetworkManager可以通过以下命令查看它接管的连接配置nmcli connection show nmcli connection show “netplan-ens33” # 假设连接名是这个第四步检查网络接口本身的状态有时候问题不在配置而在硬件或驱动。使用以下命令ip link show ens33查看接口状态。LOWER_UP表示物理链路已接通网线插好了。如果显示state DOWN你需要先激活它sudo ip link set ens33 up。然后再应用Netplan配置。第五步逐层测试网络连通性在确认配置已应用且接口已启动后进行分层测试链路层ping一下同网段的网关IP例如ping 192.168.1.1。如果不通检查IP和子网掩码是否配置正确以及物理连接。网络层ping一个外网IP如8.8.8.8。如果网关能通但外网IP不通问题很可能出在路由上。用ip route show仔细检查默认路由 (default via ...) 是否正确指向了你的网关。应用层ping一个域名如www.baidu.com。如果IP能通但域名不通问题出在DNS解析。检查/etc/resolv.conf文件看里面的nameserver是否是你配置的DNS。在systemd-networkd下这个文件通常是一个指向/run/systemd/resolve/stub-resolv.conf的符号链接由systemd-resolved服务管理。你可以用systemctl status systemd-resolved检查该服务状态并用resolvectl status查看当前的DNS配置。一个典型踩坑案例DHCP与静态配置冲突症状配置了静态IP但重启后IP又变成了另一个奇怪的地址。 排查运行ip addr show ens33发现除了你配置的静态IP接口上还有另一个由dhcp4分配的IP。 根因Netplan配置文件中虽然写了addresses但忘记将dhcp4: no明确写上。或者系统中可能存在多个Netplan配置文件/etc/netplan/*.yaml后面的文件覆盖或合并了前面文件的配置导致冲突。 解决仔细检查并统一所有相关配置文件确保目标接口的dhcp4和dhcp6在静态IP场景下被设置为no。6. 超越基础Netplan高级功能与在生产环境中的实践掌握了静态和动态IP配置你已经能应对90%的场景。但Netplan的能力远不止于此它原生支持许多复杂的网络拓扑这让它在生产环境中尤为有用。创建网桥Bridge网桥常用于虚拟化环境如KVM、LXC/Docker主机网络它将物理网卡和虚拟网卡连接在同一个二层网络中。假设我们想创建一个名为br0的网桥并将物理网卡ens33接入同时为网桥分配静态IPnetwork: version: 2 renderer: networkd ethernets: ens33: dhcp4: no # 物理网卡本身不配置IP bridges: br0: interfaces: [ens33] # 将ens33加入网桥 addresses: [192.168.1.100/24] routes: - to: default via: 192.168.1.1 nameservers: addresses: [8.8.8.8] parameters: stp: false # 对于简单环境可关闭生成树协议以加快收敛 dhcp4: no配置完成后虚拟机的虚拟网卡可以连接到br0它们就能像直接连接在ens33所在的物理网络上一样通信。绑定网卡Bonding绑定或称链路聚合能将多个物理网卡捆绑成一个逻辑接口提供冗余和增加带宽。常见的模式有balance-rr轮询、active-backup主备等。下面是一个active-backup模式的配置示例network: version: 2 renderer: networkd ethernets: eth0: dhcp4: no eth1: dhcp4: no bonds: bond0: interfaces: [eth0, eth1] addresses: [192.168.1.100/24] routes: - to: default via: 192.168.1.1 parameters: mode: active-backup primary: eth0 # 指定主接口 mii-monitor-interval: 100 # 毫秒链路检测间隔 dhcp4: no与Cloud-Init集成在云服务器如AWS EC2、Azure VM、OpenStack实例中首次启动时的网络配置通常由Cloud-Init完成。高版本Ubuntu的Cloud-Init默认也使用Netplan作为其网络配置的后端。云平台提供的“用户数据”或“元数据”中的网络配置会被Cloud-Init转换成Netplan的YAML文件写入/etc/netplan/。因此如果你在云服务器上手动修改了Netplan配置需要特别注意Cloud-Init在下一次启动时可能会覆盖你的修改。为了避免这种情况你可以禁用Cloud-Init对网络的配置修改/etc/cloud/cloud.cfg.d/下的相关文件或使用cloud-init命令。或者将你的自定义配置写在Cloud-Init生成的配置文件之后按文件名排序因为Netplan会合并处理后处理的文件中的配置项会覆盖前面的。版本控制与自动化由于Netplan配置是纯文本YAML文件非常适合纳入Git等版本控制系统进行管理。你可以将整个/etc/netplan/目录初始化成一个Git仓库每次变更都提交记录方便回滚和审计。结合Ansible等自动化工具你可以编写一个Netplan配置的Jinja2模板通过变量如主机名、IP地址池动态生成每台服务器的最终配置文件然后推送到目标服务器的/etc/netplan/目录最后执行netplan apply。这实现了网络配置的“基础设施即代码”是现代化运维的核心实践之一。从传统的ifupdown脚本切换到声明式的 Netplan初期可能会有些不适应但一旦你熟悉了它的 YAML 语法和“配置即状态”的思想就会发现它在清晰性、可维护性和与自动化工具的集成度上带来了质的提升。尤其是在管理不止一台服务器时这种优势会更加明显。我个人的经验是花点时间在测试环境里把静态IP、多网卡、网桥这些配置都亲手敲一遍用netplan try反复验证遇到问题就按上面的排查链路走一遍很快你就能对 Ubuntu 的网络层了如指掌。最后一个小技巧对于任何关键的配置变更在netplan apply之前先netplan generate看看有没有错误输出再用netplan try给自己留一个后悔的机会这个习惯能帮你避免很多深夜救火的麻烦。