VPN 切换必须从专线保留哪些东西

专线易于描述却难以替换，因为合同覆盖的不只是一根线缆。它承载了交接点、地址规划、时延预期与支持安排，而替代它的隧道会继承这四项，无论有没有人把它们写下来。当团队只复制了路由配置、把其余部分称为运维问题时，切换就会失败。请从需求出发，在旧专线退订之前，把每一条都在新路径上验证一遍。

把线路变成一份属性清单

第一个问题是旧服务实际交接了什么：带小型子网的被路由链路，还是站点之间共享的 2 层网段。这一区别决定了 IP 隧道究竟能不能复现它，因为隧道只在两个地址之间传送报文，不承载广播发现，也不承载任意 EtherType。一个把自己呈现为交换机端口的线路，与呈现为 /30 的线路属于不同的迁移。

请写下站点前缀、网关地址、把地址写进自身配置的应用，以及在环境中其他地方重叠的前缀。能在迁移后继续使用的地址规划是设计产物，而不是假设。这四份清单日后还会成为验收标准，所以要放在测试人员读得到的地方。

把新路径双向打通

隧道起来只是一半路程。远端需要回到每个本地前缀的路由，本地一侧则要为这些前缀优先选择隧道，同时不能抢走仍应经互联网外出的流量。非对称转发是只做对了一半的常见症状。请像检查自己的表一样仔细检查远端的表，因为回程路由正是没人配置的那一条。

ip route get 10.20.0.10

策略路由把分流说清楚：给属于这对站点的流量打标记，并给它一张默认走隧道的表。IPsec 提供受保护的关联，以及决定什么能进入其中的策略，但不提供它周边的路由，正如IPsec 体系结构所描述的那样。当标记匹配得过宽时，站点的普通网页流量也会进入隧道，并从错误的出口出去。

用已经演练过的回滚来完成切换

两条生存路径分属不同负责人，容易招致非对称转发，因此要在既定窗口内启用新路径，并按声明好的顺序迁移前缀。保留旧线路的配置，并保留一条不依赖任何一条隧道的带外管理通道。在应用允许的地方一次迁移一个前缀，并在两次迁移之间观察会话表。

提前决定哪些证据才授权切换、什么条件触发回滚。需要穿过失效连接去修好新 VPN 才能执行的回滚，不算回滚。把触发条件写成可测量的条件，而不是会议室里的感觉。

用线路真正承载过的流量来验收

Ping 只能证明可达，别的几乎证明不了。请测试名称解析、长连接会话、被拒绝的流，以及旧路径在不分片情况下处理过的报文尺寸。隧道与线路最常出现差异的地方就是 MTU，因为封装会占用应用以为可用的字节。请测量两个方向上不分片能通过的最大载荷，而不只是朝服务器方向。

ping -M do -s 1400 -c 3 10.20.0.10

如果 1400 字节的载荷能过、1472 不能，那么路径上限比应用预期的更小，你发现的是真实回退，而不是外观问题。把这一结果与第一步写下的需求对照，只有当这些应用的所有者接受该测量时才退掉线路。正是这份签字，才让一次成功的测试变成一次被接受的迁移。