路由持久化与安全变更：重启验收、定时回退
验证：未记录
- 适用版本
- 未记录
- 验证范围
- 尚未登记验证记录。
运行时 ip route add 不是持久化配置。正式变更要明确：谁管理网卡、配置写在哪里、如何验证新连接、失联后谁回退。本篇只在可丢弃 VM（虚拟机）上操作专用 dummy（虚拟占位）网卡，不改管理口默认路由。
1. 先确定唯一的配置来源#
systemctl is-active NetworkManager
systemctl is-active systemd-networkd
command -v netplan
ip -br address
ip -4 rule
ip -4 route show table all命令返回 inactive 不一定是故障。Netplan 是配置生成层，可调用 networkd 或 NetworkManager，不能看到两者存在就判断冲突；关键是同一接口由谁负责。
| 实际管理方式 | 应修改的位置 |
|---|---|
| Ubuntu Netplan | /etc/netplan/*.yaml；不要直接编辑生成的 /run/systemd/network/ |
| NetworkManager | nmcli connection 的连接配置，不是仅修改运行时 device |
| 原生 systemd-networkd | 对应 .network 中的 [Route] / [RoutingPolicyRule] |
| cloud-init / 配置管理 | 同步修改源配置；否则后续下发可能覆盖人工修复 |
2. Ubuntu Netplan 完整演练#
前置：Ubuntu 24.04、Netplan ≥0.107，已有 networkd renderer，可用虚拟机控制台和快照。确认 10.55.0.0/24、10.66.0.0/16、表 200、规则 110 与现有配置不冲突。下载 90-routing-lab.yaml。
该文件创建 rt-dummy0=10.55.0.10/24，表 200 仅包含到 10.66.0.0/16 的路由及网关直连路由；源/目标同时匹配才使用它，不添加默认路由。dummy 没有真正的下一跳主机，因此本节验证配置持久化，不声称能访问 10.66 网络。Netplan 配置语法
# 冲突任一项存在就停止，换隔离 VM，不覆盖已有资源。
ip link show rt-dummy0
ip -4 rule show
ip -4 route show table 200
sudo test ! -e /etc/netplan/90-routing-lab.yaml
sudo install -m 600 90-routing-lab.yaml /etc/netplan/90-routing-lab.yaml
sudo netplan generate第一条在网卡不存在时应报错；表未建立也可报不存在。必须人工确认规则/表没有被其他功能使用。netplan generate 只检查并生成配置，不代表网络已实际应用。
先安排一个两分钟回退，只清理本实验新增的文件、规则和接口：
sudo tee /run/routing-lab-rollback.sh >/dev/null <<'SH'
#!/bin/sh
rm -f /etc/netplan/90-routing-lab.yaml
netplan apply
ip -4 rule del priority 110 from 10.55.0.10/32 to 10.66.0.0/16 lookup 200 2>/dev/null || true
ip link del rt-dummy0 2>/dev/null || true
SH
sudo chmod 700 /run/routing-lab-rollback.sh
sudo systemd-run --unit=routing-lab-rollback --on-active=120s /run/routing-lab-rollback.sh
sudo netplan try --timeout 60在另一个控制台/会话检查接口、规则和路由；确认新 SSH（安全远程登录）连接与原有服务仍可用，再在 try 提示中确认。成功后取消回退定时器：
ip -br address show rt-dummy0
ip -4 rule show
ip -4 route show table 200
ip -4 route get 10.66.1.1 from 10.55.0.10
sudo systemctl stop routing-lab-rollback.timer
sudo systemctl is-active routing-lab-rollback.timer最后一条应返回 inactive。若 netplan try 提示不支持某项自动回退或应用失败，先执行回退脚本并核对，不盲目确认。虚拟设备的回退有局限，超时也必须验证实际状态；VM 控制台和快照是恢复手段，不能仅依赖 SSH 或自动回退。netplan try 限制
完成后仅重启这台演练 VM：sudo reboot。重新登录，重复四条 ip 检查；表 200 与规则 110 应仍存在，才算持久化通过。清理时删除配置并执行 sudo netplan apply，再按回退脚本精确删除可能残留的规则/虚拟接口；不要清空其他表或重置整个网络。
3. NetworkManager 环境的对应操作#
只在由 NetworkManager 管理的另一台演练 VM 执行，不要和上面的 Netplan 配置混装。同样先检查网段、连接名与接口名未占用：
nmcli connection show
ip link show rt-nm0
sudo nmcli connection add type dummy ifname rt-nm0 con-name routing-lab ipv4.method manual ipv4.addresses 10.55.0.10/24 ipv4.never-default yes ipv6.method disabled connection.autoconnect yes
sudo nmcli connection modify routing-lab ipv4.routes '10.66.0.0/16 10.55.0.1 100'
sudo nmcli connection up routing-lab
ip route get 10.66.1.1 from 10.55.0.10
nmcli -f ipv4.routes connection show routing-lab这是普通 main 表静态路由版本，不冒充上节的策略路由。重启演练 VM 后应仍存在；清理用 sudo nmcli connection delete routing-lab。真实管理口变更应先配置 checkpoint 或独立定时回退，并从新连接验证。nmcli 手册
4. 生产变更的最小验收#
保存旧配置与运行态 → 校验语法 → 确认带外入口/回退可执行 → 增加新路径 → 从正确源地址测真实业务和新 SSH 连接 → 再移除旧路径 → 重启验收。不要以“旧 SSH 连接还没断”判断新路由正确，也不要直接复制某台主机网卡名、网关与 metric 到所有服务器。
本仓库已检查 YAML 结构与路由作用范围，尚未完成目标系统上的配置生成验证；持久化章节的真实 VM 重启与失联回退必须在目标发行版执行并记录，不能由命名空间实验代替。