更换 ISP 而不重新编址站点 VPN 地址

一个分支机构更换了互联网服务提供商，文件服务器却保留原有地址。这一结果在路由式站点 VPN 中很正常，却会让那些认为隧道端点地址就是应用地址的人感到意外。两者处在设计的不同层次，只有其中一个发生了移动。把它们当成一回事，正是服务商迁移演变成重新编址项目的原因。

两套各自独立变化的地址方案

内层方案描述应用使用的私有地址：位于 10.55.8.20 的分支服务器、将其路由过去的总部前缀，以及回程路由。外层方案描述两个网关如何互相到达：对端地址、监听端口以及穿越互联网的路径。

更换服务商影响的是外层方案。它本身并不要求内层方案改变。

把两套清单分开维护，正是即便应用已经自行加密流量仍要运行覆盖网络的实际理由。覆盖网络给你稳定的内层拓扑，能经受外层的变动。应用保留自己的地址、防火墙规则和 DNS 记录。只有传输条目改变，那是一次小得多的评审。

外层隧道承载内层会话

在网关到网关的隧道中，外层 IP 头对两个网关寻址。内层头仍然指明实际的应用端点。RFC 7296 的网关到网关描述把它当作通过隧道端点投递流量的普通路由。

正因如此，分支服务器可以在网关公网地址变化时保留 10.55.8.20。内层数据包根本不包含服务商的地址。

这种分离是设计属性，不是自动保证。如果替换的上行链路无法建立受支持的隧道，或者内层路由没有重新安装，即使地址没变，应用也会失去路径。

服务商迁移仍有检查清单

外层清单有五项：对端地址或受维护的名称、监听端与任何上游过滤、路径中的转换、预期的对端身份，以及另一网关被允许的设置。每一项都可能单独失效。在更换承载管理的链路时，要保留一条独立的恢复通道。在上行链路切换期间切断远程访问，是你自己造成的中断。

之后检查分支前缀、两个方向的路由、保护策略以及一条真实的应用流。刚刚完成认证的隧道并不会修正指向旧私有子网的路由。

与其他已连接站点的地址重叠是另一项规划问题。更换服务商不会制造它，但迁移通常正是它暴露出来的时机。

无法保留的部分：公网来源与会话

稳定的私有服务器地址不是稳定的公网来源。如果浏览直接通过新服务商出去，网站看到的就是新的面向服务商的地址。

要让该地址保持稳定，需要有意识的出口设计，并自带可用性与策略。它不会随隧道免费附送。

已建立的会话同样熬不过路径变化。隧道可以在数秒内重新建立，却仍会打断固定在旧路径上的长连接。请把切换安排在可以接受重连的时间窗内。除非测试过具体客户端及其超时，不要声称迁移会毫无察觉。

用四项检查确认迁移

变更之后，按顺序确认四件事：隧道已与预期对端建立、通往分支前缀的内层路由存在、策略允许该应用流、应用有响应。每一项都有自己的命令。

在 Linux 网关上，这三项覆盖了该列表的中间部分：

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

把传输地址放在一份清单里，应用地址放在另一份里。只更新真正移动过的条目。因为隧道外层地址变化就重新编址内部依赖，是可以避免的工作。