解决Ubuntu重启后网络配置丢失的终极方案

1. 问题现象与初步排查

Ubuntu系统重启后网络配置丢失是个经典问题，我最近在给公司部署Ubuntu 22.04 LTS服务器集群时就遇到了这个头疼的情况。每次重启后，原本配置好的静态IP、DNS设置全都恢复默认，导致自动化部署脚本全部失效。经过三天的问题追踪，终于摸清了背后的完整机制。

首先需要确认的是网络配置丢失的具体表现。通过ifconfig或ip a命令查看，可能会发现以下几种典型情况：

• 原本配置的静态IP变成了DHCP自动获取的地址
• 自定义的网络接口名称（如eth0、ens33）恢复为默认命名
• /etc/netplan/下的配置文件被覆盖或重置
• 网络服务无法正常启动，出现"Device not managed"错误

重要提示：在开始修复前，务必先执行ip a和cat /etc/netplan/*.yaml记录当前配置，并与重启前的配置对比，这能帮助快速定位被修改的具体参数。

2. 罪魁祸首：cloud-init的自动重置机制

经过多次测试和日志分析（journalctl -u cloud-init），发现根本原因是cloud-init服务在每次启动时会"热心"地重置网络配置。这个设计本意是为了云环境下的自动初始化，但在物理机或常驻虚拟机中就成了麻烦制造者。

cloud-init的工作流程分为几个阶段：

1. 启动时检测系统环境（/run/cloud-init/instance-data.json）
2. 读取网络配置数据源（包括缓存和云平台metadata）
3. 应用网络配置到netplan
4. 生成最终的/etc/netplan/50-cloud-init.yaml

关键问题在于：即使没有云平台metadata，cloud-init仍会生成默认配置覆盖现有设置。通过分析/var/lib/cloud/instance/目录下的缓存文件，可以确认这一点。

3. 彻底解决方案：禁用cloud-init网络配置

3.1 方法一：修改cloud-init配置（推荐）

这是最干净的解决方案，既保留cloud-init的其他功能，又阻止其干扰网络配置：

bash复制sudo vim /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

添加以下内容：

yaml复制network:
  config: disabled

然后执行：

bash复制sudo cloud-init clean && sudo reboot

3.2 方法二：锁定netplan配置文件

对于不能禁用cloud-init的环境，可以采用文件锁机制：

bash复制sudo chattr +i /etc/netplan/50-cloud-init.yaml

这会使文件不可修改，但要注意后续手动更新配置时需要先解除锁定：

bash复制sudo chattr -i /etc/netplan/50-cloud-init.yaml

3.3 方法三：完全移除cloud-init

如果是本地长期使用的系统，可以考虑彻底移除：

bash复制sudo apt purge cloud-init
sudo rm -rf /etc/cloud/ /var/lib/cloud/

但要注意这会影响某些云平台功能，如AWS的用户数据脚本。

4. 正确配置静态IP的完整流程

在解决cloud-init问题后，还需要确保静态IP配置本身正确。以下是经过验证的标准操作流程：

4.1 创建自定义netplan配置

bash复制sudo vim /etc/netplan/01-static.yaml

示例配置（适配大多数物理服务器）：

yaml复制network:
  version: 2
  renderer: networkd
  ethernets:
    enp5s0:
      dhcp4: no
      addresses: [192.168.1.100/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]
      optional: true

4.2 应用配置并测试

bash复制sudo netplan generate
sudo netplan apply

验证步骤：

1. ip a show enp5s0 查看IP是否正确
2. ping -c4 8.8.8.8 测试外网连通性
3. nslookup example.com 检查DNS解析

4.3 持久化配置技巧

为防止其他服务干扰，建议：

1. 将自定义配置文件命名为01-前缀，确保优先加载
2. 设置文件权限为644防止误修改：

bash复制sudo chmod 644 /etc/netplan/01-static.yaml

5. 进阶排查与疑难解答

即使按照上述步骤操作，仍可能遇到特殊情况。以下是几种常见问题及解决方案：

5.1 网络接口名称变化问题

现象：重启后eth0变成ens33等随机名称
解决方法：

1. 使用MAC地址固定接口名：

yaml复制network:
  ethernets:
    enp5s0:
      match:
        macaddress: 00:11:22:33:44:55
      set-name: eth0

2. 或者完全禁用Predictable Network Interface Names：

bash复制sudo vim /etc/default/grub
# 添加 net.ifnames=0 biosdevname=0
GRUB_CMDLINE_LINUX="... net.ifnames=0 biosdevname=0"
sudo update-grub

5.2 NetworkManager与networkd冲突

现象：配置正确但服务无法启动
解决方案：

1. 确认系统使用的渲染器：

bash复制ps aux | grep -E 'NetworkManager|networkd'

2. 统一使用networkd（服务器推荐）：

bash复制sudo systemctl stop NetworkManager
sudo systemctl disable NetworkManager
sudo apt install networkd-dispatcher

5.3 虚拟化环境特殊配置

在VMware/KVM中需要特别注意：

1. 关闭虚拟机克隆保护：

bash复制sudo truncate -s 0 /etc/machine-id
sudo systemd-machine-id-setup

2. 对于VMware，安装open-vm-tools时添加：

bash复制sudo apt install open-vm-tools-desktop

6. 系统层面的防御措施

为防止其他系统组件干扰网络配置，建议实施以下加固措施：

1. 禁用不必要的网络服务：

bash复制sudo systemctl mask systemd-networkd.socket
sudo systemctl stop systemd-networkd.socket

2. 创建配置变更监控脚本（/usr/local/bin/netmon.sh）：

bash复制#!/bin/bash
inotifywait -m /etc/netplan -e create,modify,delete |
while read path action file; do
    logger "Netplan config changed: $file via $action"
    diff -u /etc/netplan/.bak/$file /etc/netplan/$file | logger
done

设置开机启动：

bash复制sudo cp /etc/netplan/* /etc/netplan/.bak/
sudo systemctl enable netmon.service

3. 定期配置备份方案：

bash复制sudo crontab -e
# 添加：
0 3 * * * tar czf /var/backups/netplan-$(date +\%Y\%m\%d).tar.gz /etc/netplan/

经过上述全套处理，我的20台服务器已经稳定运行3个月没有出现网络配置重置问题。这个问题的核心在于理解Ubuntu网络配置的层次结构：cloud-init → netplan → networkd/NetworkManager，任何一层配置不当都会导致连锁反应。建议在重要环境变更前，先在小规模测试机上验证配置效果。