在不中断的情况下把一整个子网迁到新的 VPN 隧道

把新隧道拉起来，搬走一整个子网，然后这个子网开始间歇性失败，而其他一切完全正常。迁移到一半的 VPN 正是这样失败的，因为隧道从来都不是难的那部分。路径还包括哪条路由胜出、哪些选择器匹配、访问规则允许什么、回包怎么走，以及旧设计做过的任何转换。只搬隧道，上面这些你一样都没搬。

隧道只是路径里简单的那一半

部分迁移后出现间歇性失败，通常说明两条路径同时都成立。有些流走新隧道，有些还留在旧隧道，于是有状态设备会看到回包从请求从未走过的路径回来。两条路径并不自动比一条更安全；它们是两件可能互相矛盾的事。要盯抖动报告而不是隧道计数器，因为计数器全程都会显示健康。

有用的第一个问题不是哪条隧道更好。而是今天哪些流走哪条路径，以及请求和回包是否得到同一个答案。

先把目的地建好，再去偏好它

确认对端兼容，并且新隧道承载了你想要的地址范围。趁它还是非首选路径时，把它需要的转发和服务权限加好，这样切换本身只改变选择，别的都不动。

问清对端站点会怎么把流量送回来。如果回包仍然从旧隧道出去，新的本地路由就会造成不对称，或者被有状态防火墙丢掉。转换也要进设计，理由相同：源地址变了，回程路径也跟着变。

小范围切换，并且知道怎么退回来

说清楚是哪条子网，以及平台支持的、用来优先它的新路由或选择器的机制。基于策略的定义并不总像路由度量那样运作，所以在假定更具体的匹配会赢之前，先读你所用实现里重叠策略的规则。

搬一条子网，而不是搬一个站点。把管理访问留在你不碰的路径上，并在动手之前写下回滚方案：哪条路由或策略回退、谁来做、做的时候他们怎么保持连接。

不对称与过期状态

防火墙和 NAT 设备会记住一条流用过的接口。当请求和回包走不同隧道时，即使每条路径单独都能通，设备也可能把回包丢掉。用变更之后新开的流来测，因为已建立的会话可能还会继续走旧路径好几个小时。

如果观测到的源地址变了，就把所有提到旧地址的策略都找出来。悄悄改了源地址的迁移，会打破那些没人归进 VPN 设计的规则。

把两个答案都验证过，再退役旧策略

从被迁移子网上的一台普通主机，访问目标服务，检查观测到的源地址和回包接口。然后再测一个本该留在旧隧道上的网络，因为只有两个答案都对，迁移才算完成。第二个测试才是人们会跳过的那个，也正是它能抓住比你预想更宽的选择器。

只有当不再有剩余子网依赖旧策略时，才把它退役，并把最终路由连同归属人一起记进选择器清单。完成不是新隧道报告自己起来了，而是每个网络都走在它该走的路径上。