Ubuntu网络配置演进：从ifupdown到Netplan的YAML声明式管理

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这类自动化工具所青睐的，这使得在大量服务器上批量部署和变更网络配置变得非常高效。

所以，当你面对一台高版本Ubuntu（18.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（传统）、enp3s0（PCIe位置命名）、ens33（VMware虚拟机常见）等。请务必使用你自己系统上的真实接口名。
• 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.1，DNS服务器使用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

现在，我们来详细解释每一个配置项的作用和背后的逻辑：

1. addresses:这是一个列表项（以-开头），用于指定一个或多个静态IP地址。192.168.1.100/24是CIDR表示法，/24等同于子网掩码255.255.255.0。这里的关键是，Netplan要求你必须带上子网前缀长度（即/24），而不能像旧配置里只写IP和独立的子网掩码。

2. routes:用于配置路由表。- to: default是一个特殊的目标，它表示“默认路由”，即所有目标地址不匹配其他更具体路由的数据包，都将通过这条路由发出。via: 192.168.1.1指定了到达这个“默认”目标的下一跳网关地址。在大多数局域网设置中，配置默认路由就足够了。如果你有复杂的多网卡、多网关需求，可以在这里定义更多具体的路由条目。

3. nameservers:用于配置DNS解析。addresses:后面是一个YAML列表（用方括号[]括起来，逗号分隔），列出了DNS服务器的IP地址。你可以根据需要添加多个。这里我使用了Google的公共DNS。对于内网环境，你通常需要换成公司或家庭路由器的DNS（如192.168.1.1）。

4. 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. 实战配置二：配置动态IP（DHCP）与多网卡场景

动态IP配置相对简单，适用于大多数桌面环境或服务器中无需固定地址的网卡。继续使用ens33为例，启用DHCPv4的配置如下：

network: version: 2 renderer: networkd # 桌面版可改为 NetworkManager ethernets: ens33: dhcp4: true dhcp6: false # 根据需求开启或关闭IPv6 DHCP

是的，就是这么简单。将dhcp4设为true，Netplan就会在启动该接口时通过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获取了默认网关）时，可能会引起路由冲突，导致网络流量从非预期的接口流出。这是多网卡配置中的一个经典坑。为了避免这个问题，对于非主出口的网卡，我们通常有两种做法：

1. 不配置默认网关：在静态配置中，只为出口网卡设置routes:里的to: default。对于DHCP获取的网卡，如果可能，在DHCP服务器端配置不要下发默认网关选项。
2. 使用策略路由：这是更高级和精确的控制方式。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。你需要确保对应的服务是活跃的。

• 如果你配置中指定或默认使用networkd：

  sudo 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配置。

第五步：逐层测试网络连通性在确认配置已应用且接口已启动后，进行分层测试：

1. 链路层：ping一下同网段的网关IP（例如ping 192.168.1.1）。如果不通，检查IP和子网掩码是否配置正确，以及物理连接。
2. 网络层：ping一个外网IP（如8.8.8.8）。如果网关能通但外网IP不通，问题很可能出在路由上。用ip route show仔细检查默认路由 (default via ...) 是否正确指向了你的网关。
3. 应用层：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接入，同时为网桥分配静态IP：

network: 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在下一次启动时可能会覆盖你的修改。为了避免这种情况，你可以：

1. 禁用Cloud-Init对网络的配置：修改/etc/cloud/cloud.cfg.d/下的相关文件，或使用cloud-init命令。
2. 或者，将你的自定义配置写在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给自己留一个后悔的机会，这个习惯能帮你避免很多深夜救火的麻烦。