1. 项目概述：为什么Ubuntu 20.04的网络配置是个“坎”？

如果你刚接触Ubuntu 20.04，尤其是从更早版本（比如16.04、18.04）迁移过来，或者第一次在物理机或虚拟机上安装它，十有八九会在网络配置上卡壳。明明在安装向导里看着网络是通的，怎么一进系统，ping不通网关，浏览器也打不开网页？更让人困惑的是，熟悉的ifconfig命令不见了，输入后系统提示你要安装net-tools。这个变化，正是Ubuntu 20.04网络管理新旧时代交替的标志。从18.04版本开始，Ubuntu官方就力推Netplan作为默认的网络配置工具，到了20.04这个LTS长期支持版本，Netplan已经彻底站稳了脚跟，而传统的ifconfig、/etc/network/interfaces那一套则退居二线。

所以，当你遇到“Ubuntu20.04网络配置的问题”时，核心往往不是网络硬件或驱动的问题，而是不熟悉Netplan这套新的配置范式。它用YAML格式的配置文件取代了原先的脚本式配置，理念上更强调声明式和跨后端兼容（支持networkd和NetworkManager）。对于习惯了旧方法的运维人员或开发者来说，这无疑增加了一层学习成本。但一旦掌握，你会发现它的配置更清晰、更易于版本管理，尤其是在服务器自动化部署场景下优势明显。这篇内容就是帮你彻底跨过这道坎，从原理到实操，把Ubuntu 20.04的网络配置安排得明明白白，无论你是在物理服务器、本地虚拟机（VMware/VirtualBox）还是云主机上。

2. 核心思路：理解Netplan的架构与工作流

在动手改配置之前，我们必须先搞清楚Netplan是怎么工作的。盲目修改/etc/netplan/*.yaml文件然后运行sudo netplan apply，如果不懂背后逻辑，出了问题只会更懵。

2.1 Netplan的定位：一个配置生成器

首先要纠正一个常见的误解：Netplan本身并不直接管理网络。它更像一个“翻译官”或“配置生成器”。你的任务是编写一个人类可读的YAML文件（声明“我想要什么样的网络”），Netplan读取这个文件后，会根据系统当前使用的“渲染器”，将其翻译成对应后端服务能理解的配置。

• 渲染器：这是Netplan的核心概念。Ubuntu 20.04默认支持两种：
  1. networkd：使用systemd-networkd作为后端。这是服务器版本和最小化安装的默认选择，轻量、无图形界面依赖，非常适合服务器环境。
  2. NetworkManager：使用NetworkManager作为后端。这是桌面版本的默认选择，它提供了图形化网络管理工具，更适合需要频繁切换Wi-Fi、移动网络等复杂场景的桌面用户。

你的配置文件中必须通过renderer:字段明确指定使用哪一个。很多配置错误就源于此，比如在服务器上误用了NetworkManager，或者在桌面上写的配置因NetworkManager的图形设置冲突而未生效。

2.2 配置文件的位置与优先级

Netplan的配置文件存放在/etc/netplan/目录下，文件名以.yaml结尾。这里有几点关键：

1. 文件命名：虽然可以任意命名，但建议使用有意义的名称，如01-netcfg.yaml、50-cloud-init.yaml。系统会按字母数字顺序读取所有.yaml文件并合并其配置。后读取的文件会覆盖先读取文件中冲突的配置。所以如果你看到50-cloud-init.yaml（通常是云提供商如AWS、Azure通过cloud-init注入的配置），你的自定义配置文件名最好排在它前面（比如01-）或后面（比如99-），以确保你的配置能生效或覆盖它。
2. YAML语法：缩进必须使用空格，绝对不能使用Tab键。冒号:后面必须跟一个空格。层级关系完全靠缩进体现，对格式非常敏感。

2.3 核心工作流程

整个配置过程遵循一个清晰的流程，理解它有助于排查问题：

1. 编辑：使用文本编辑器（如sudo nano /etc/netplan/01-netcfg.yaml）编写或修改YAML配置文件。
2. 验证：在应用前，强烈建议使用sudo netplan generate命令。这个命令会检查YAML文件的语法是否正确，并尝试生成后端配置。如果语法有错，它会给出明确的错误行号提示。这是一个非常重要的安全网。
3. 应用：使用sudo netplan apply命令让配置生效。这个命令会做几件事：停止受影响的网络接口，根据新配置生成后端（networkd或NetworkManager）的配置文件，然后启动接口并应用新配置。
4. 调试：如果配置未生效，使用sudo netplan --debug apply。--debug参数会输出详细的执行过程，告诉你它每一步在做什么，在哪里卡住了，是排查复杂问题的利器。

3. 实战配置解析：从静态IP到多网卡绑定

理论说再多，不如看几个实实在在的例子。下面我会针对最常见的几种场景，给出详细的YAML配置和逐行解释。

3.1 场景一：为服务器配置静态IP地址

这是最基础、最频繁的需求。假设你有一台Ubuntu 20.04服务器，网卡名称为ens33（你的可能是eth0、enp0s3等，请用ip link show命令确认），你想为它设置静态IP。

# /etc/netplan/01-netcfg.yaml network: version: 2 renderer: networkd # 服务器环境通常用networkd ethernets: ens33: # 你的网卡设备名 addresses: - 192.168.1.100/24 # 静态IP和子网掩码（CIDR格式） routes: - to: default via: 192.168.1.1 # 默认网关地址 nameservers: addresses: - 8.8.8.8 # 首选DNS - 8.8.4.4 # 备用DNS search: [localdomain] # DNS搜索域

逐行拆解与注意事项：

• network:：根节点。
• version: 2：必须声明，表示使用Netplan v2的语法。
• renderer: networkd：指定后端为systemd-networkd。
• ethernets:：定义有线以太网设备。
• ens33:：子节点，键名必须是真实的网络接口名称。
• addresses:：指定IP地址列表。/24是CIDR表示法，等同于子网掩码255.255.255.0。这里可以配置多个IP，实现单网卡多IP。
• routes:：路由配置。to: default表示默认路由（即所有非本地流量走哪里）。via指定网关IP。
• nameservers:：DNS配置。addresses是DNS服务器IP列表。search是搜索域，当你不输入完整域名时，系统会尝试拼接这些域。

重要提示：在虚拟机（如VMware、VirtualBox）中配置静态IP时，务必确保你设置的IP段与虚拟网络的设置（如VMware的NAT网络或桥接网络）相匹配。例如，如果VMware虚拟网络的网段是192.168.10.0/24，你的静态IP就必须设在这个范围内，网关也要对应虚拟网络网关（通常是192.168.10.2或192.168.10.1）。否则必然无法连通。

配置完成后，执行：

sudo netplan generate # 语法检查 sudo netplan apply # 应用配置

然后用ip addr show ens33查看IP是否已分配，用ping 192.168.1.1测试网关连通性。

3.2 场景二：桌面环境使用NetworkManager（含Wi-Fi）

对于Ubuntu 20.04桌面版，你可能希望继续使用图形界面管理网络，但同时想用Netplan来定义一些基础配置或固定某些设置。

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

是的，一个最简单的配置就是这样，它告诉系统：“网络交给NetworkManager全权管理”。所有配置都可以通过桌面右上角的网络图标进行图形化设置。

但是，如果你想用Netplan为桌面环境固定一个DHCP配置，或者混合管理（比如有线用Netplan固定，无线用图形界面切换），可以这样：

network: version: 2 renderer: NetworkManager ethernets: enp3s0: # 有线网卡 dhcp4: yes # 启用DHCPv4 dhcp6: yes # 启用DHCPv6（可选） optional: true # 标记为可选，避免系统启动时因此接口未就绪而等待超时 wifis: wlp2s0: # 无线网卡 dhcp4: yes access-points: "你的Wi-Fi名称": password: "你的Wi-Fi密码"

关于Wi-Fi配置的坑点：在Netplan中配置Wi-Fi密码，密码会以明文形式保存在YAML文件中。虽然文件权限是root可读，但这仍然存在安全风险。对于桌面用户，更推荐的做法是只在Netplan中启用NetworkManager渲染器，具体的Wi-Fi连接通过图形界面或nmcli命令在NetworkManager中添加和保存。NetworkManager会将密码加密存储在/etc/NetworkManager/system-connections/目录下。

3.3 场景三：配置链路聚合（Bonding）或网桥（Bridging）

对于高级网络需求，如高可用（bonding）或虚拟化（bridging），Netplan同样支持。

示例：配置一个Mode 4 (802.3ad) 的动态链路聚合

network: version: 2 renderer: networkd bonds: bond0: interfaces: [ens33, ens34] # 绑定两个物理网卡 parameters: mode: 802.3ad # 聚合模式 lacp-rate: fast mii-monitor-interval: 100 addresses: [192.168.1.200/24] routes: - to: default via: 192.168.1.1 nameservers: addresses: [8.8.8.8, 8.8.4.4]

示例：创建一个网桥，供KVM虚拟机使用

network: version: 2 renderer: networkd ethernets: ens33: # 物理网卡 dhcp4: no # 物理网卡本身不获取IP bridges: br0: # 网桥设备 interfaces: [ens33] # 将物理网卡加入网桥 dhcp4: yes # 网桥获取IP parameters: stp: false # 在简单环境中可关闭生成树协议 forward-delay: 0

应用此类复杂配置后，务必使用ip link show检查bond或bridge接口是否创建成功，状态是否为UP。

4. 排错实录：那些年我踩过的Netplan的坑

即使理解了原理，照着例子写配置，在实际操作中还是会遇到各种问题。下面是我总结的几个高频故障点及解决方法。

4.1 问题一：执行sudo netplan apply后网络断开，SSH连接丢失

这是最令人紧张的情况，通常发生在远程配置服务器时。原因和解决方案：

1. 配置错误导致接口down掉：比如IP地址冲突、网关不可达、子网掩码写错。预防措施：在远程操作前，务必先通过sudo netplan generate验证语法。如果可能，在应用新配置的同时，开启一个ping到网关或已知可达IP的长时间任务（如ping -i 5 192.168.1.1）。如果ping中断，说明配置可能有问题，你需要通过控制台（物理机或云平台的VNC）登录修复。
2. 补救方法：如果已经断开，通过控制台登录，使用sudo netplan apply回滚到上次成功的配置？不，Netplan没有自动回滚。你需要直接编辑YAML文件修正错误。一个备用方案是，在修改前备份原配置：sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.backup。出错后可以cp回去再apply。

4.2 问题二：配置看似正确，但IP地址就是获取不到或不生效

按照“配置-生成-应用”三步走，netplan apply也没报错，但ip addr显示的还是老地址或者没有地址。

1. 检查渲染器冲突：这是最常见的原因。如果你在服务器（默认networkd）上配置了renderer: NetworkManager，但NetworkManager服务根本没安装或没启动，配置自然不会生效。用systemctl status NetworkManager和systemctl status systemd-networkd看看哪个是活跃的。确保你的YAML文件中的renderer与系统活跃的后端一致。
2. 检查NetworkManager的覆盖：在桌面版，即使Netplan配置了静态IP，如果NetworkManager的图形界面或nmcli为同一个接口配置了DHCP或另一个静态IP，NetworkManager的配置优先级更高。你需要确保在NetworkManager中该连接是“已断开”或“自动连接”已关闭，或者将其配置从NetworkManager中删除（nmcli con delete “连接名”）。
3. 检查配置文件优先级：/etc/netplan/目录下可能有多个文件。用ls -la /etc/netplan/查看。比如存在一个50-cloud-init.yaml，它里面可能也定义了ens33接口并使用DHCP。你的01-开头的文件虽然先被读取，但50-文件后读取，其中的DHCP配置会覆盖你的静态IP配置。解决方法：要么在你的文件中删除冲突接口的定义（让cloud-init管理），要么在cloud-init的配置中禁用网络配置，或者确保你的配置在顺序上能覆盖它（用99-开头）。
4. 接口名称不对：虚拟机克隆或某些硬件变更后，网卡名称可能会变（如从ens33变成ens34）。始终用ip link show或ls /sys/class/net确认当前的接口名。

4.3 问题三：DNS解析失败（能ping通IP，但打不开网址）

ping 8.8.8.8通，但ping google.com不通。

1. 检查Netplan的DNS配置：确保nameservers:下的IP是正确的、可访问的DNS服务器。可以临时修改为公共DNS如114.114.114.114测试。
2. 检查/etc/resolv.conf：这个文件是实际负责DNS解析的。在Ubuntu 20.04上，它通常是一个指向/run/systemd/resolve/stub-resolv.conf的符号链接，由systemd-resolved服务管理。运行sudo systemctl status systemd-resolved确保服务运行。有时Netplan的配置可能没被systemd-resolved正确接收。可以尝试重启该服务：sudo systemctl restart systemd-resolved。
3. 手动测试DNS：使用nslookup google.com 8.8.8.8或dig google.com @8.8.8.8来指定DNS服务器测试，如果成功，说明问题出在本地的DNS解析服务配置上。

4.4 问题四：虚拟机（VMware/VirtualBox）网络配置的特殊问题

在虚拟机中配置网络，除了IP段要匹配，还有几个专属陷阱：

1. NAT模式下的“外部”访问：如果你使用NAT模式，虚拟机通过宿主机的IP共享上网。在这种情况下，虚拟机获取的IP通常是由虚拟DHCP服务器分配的一个私有网段（如192.168.10.0/24），网关是这个网段的.2或.1地址。你的Netplan配置应该设置为DHCP（dhcp4: yes）来自动获取，或者静态IP必须设在这个NAT网段内。试图配置成宿主机的物理网络段（如192.168.1.x）是行不通的。
2. 桥接模式下的IP冲突：在桥接模式下，虚拟机会像一台真实设备一样出现在你的物理局域网中。你需要为它分配一个与物理网络同网段且未被其他设备占用的IP地址。如果出现IP冲突，网络会极不稳定。
3. VirtualBox的“仅主机(Host-Only)网络”：这种模式下，虚拟机和宿主机之间会形成一个独立的私有网络。你需要为这个虚拟网络适配器配置一个静态IP，通常网段是192.168.56.0/24（VirtualBox默认），宿主机通常是192.168.56.1。

5. 必备工具与诊断命令

告别ifconfig，拥抱新的网络调试工具集。这些命令能让你在遇到问题时快速定位。

1. ip命令族（替代ifconfig、route）：

   • ip link show或ip a：查看所有网络接口的链路层状态（MAC地址、UP/DOWN状态）。
   • ip addr show或ip a：查看所有网络接口的IP地址信息。
   • ip route show或ip r：查看系统路由表。
   • ip neigh show：查看ARP邻居表（相当于arp -a）。

2. netplan命令族：

   • sudo netplan generate：干运行，生成配置但不应用，用于语法检查。
   • sudo netplan apply：应用当前/etc/netplan/下的所有配置。
   • sudo netplan --debug apply：最强排错命令，显示详细的应用过程。
   • sudo netplan try：应用配置并提供一个回滚窗口（默认120秒）。如果在超时前你不确认，配置会自动回滚。非常适合远程操作，防止配置错误导致失联。

3. 网络连通性测试：

   • ping <IP>：测试到目标IP的ICMP连通性。
   • curl -I <URL>：测试HTTP连接，获取响应头。
   • mtr <IP或域名>：结合traceroute和ping功能的强大工具，能看到每一跳的丢包和延迟。

4. DNS诊断：

   • systemd-resolve --status：查看systemd-resolved服务的详细状态和DNS配置。
   • dig <域名>或nslookup <域名>：手动进行DNS查询。

5. 查看后端服务状态：

   • sudo systemctl status systemd-networkd：查看networkd服务状态。
   • sudo networkctl list：以更友好的方式列出networkd管理的所有链接。
   • sudo systemctl status NetworkManager和nmcli device status：查看NetworkManager状态和设备。

6. 从理论到肌肉记忆：一个完整的配置演练

让我们模拟一个真实场景，从头配置一台Ubuntu 20.04服务器的静态网络，并加入排错步骤。

初始状态：刚安装完系统，只有一张网卡ens33，通过DHCP获取了一个临时IP（比如192.168.1.155）。

目标：配置为静态IP192.168.1.100/24，网关192.168.1.1，DNS8.8.8.8和1.1.1.1。

步骤：

1. 探查现状：

   ip a show ens33 # 确认接口名和当前IP ip route show default # 查看当前默认网关 cat /etc/resolv.conf # 查看当前DNS

2. 备份与创建配置：

   cd /etc/netplan sudo cp 01-netcfg.yaml 01-netcfg.yaml.bak # 如果有原文件则备份 sudo nano 01-netcfg.yaml # 使用你喜欢的编辑器

3. 编写配置：

   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, 1.1.1.1]

4. 语法检查与试运行：

   sudo netplan generate # 应该输出“Configuration is valid” # 为了安全，先使用try命令 sudo netplan try --timeout 30

   此时，你有30秒时间测试新网络。立刻打开另一个终端窗口，尝试：

   ping 192.168.1.1 # 测试新网关 ping 8.8.8.8 # 测试外网连通性 nslookup google.com # 测试DNS解析

   如果一切正常，回到netplan try的终端按回车确认。如果网络不通，不要确认，30秒后它会自动回滚。

5. 正式应用与验证：

   sudo netplan apply # 如果try成功了，或者你决定直接应用 ip a show ens33 # 确认IP已变更为192.168.1.100 ip route show # 确认默认路由指向192.168.1.1 systemd-resolve --status | grep -A5 "DNS Servers" # 确认DNS服务器

如果netplan try期间测试失败怎么办？

• 检查IP是否冲突：在局域网内ping一下192.168.1.100，看是否有其他设备响应。
• 检查网关IP是否正确：确认你的路由器或上级网关确实是192.168.1.1。
• 检查网线/虚拟网络连接：物理机检查网线，虚拟机检查网络适配器是否已连接。
• 使用sudo netplan --debug apply查看详细错误日志。

这个流程形成了肌肉记忆后，配置Ubuntu 20.04的网络就不再是玄学，而是一个可控、可预测、可排错的标准操作。关键在于理解Netplan作为“配置生成器”的角色，明确渲染器，并善用generate、try、--debug这些安全机制。