站点间 VPN 上选静态路由还是路由协议

两种方案都能在站点之间传递数据包，所以决策不在于哪种协议更新，隧道大小也决定不了它。决定它的是三个条件：有多少前缀会变化、变化多频繁；设计是否需要路径之间的自动故障切换；以及团队凌晨三点能运维多少控制面机制。诚实回答这三项，选择通常会自己浮现。本文余下部分讲每个答案要付出的代价。

三个条件决定取舍

第一个条件是变化。少数稳定、归属清晰的大网段可以多年手工维护，每条路由仍是一行有人能读懂并核对的内容。随项目上线下线而搬家的几十个前缀则是另一回事，因为每一次搬迁都必须抵达每台还记得旧路径的设备。

第二个是故障行为。当备用路径要在无人察觉的情况下生效，必须有机制发现故障并撤回路由。静态路由只能依靠跟踪或条件安装来完成，而且只覆盖你事先想到的那些故障。

第三个是对第二套控制面的胃口。路由协议会带来会话、认证、过滤和选路策略，每一项都需要监控和变更流程。这是长期的运维成本，不是一次性的配置任务。

第三段下面的表是精简版，紧随其后的三节解释每一行为什么处在它的位置上。选择之前请把各行与自己的站点数对照一遍，因为忽略运维成本的决策只算半个决策。

静态路由必须在隧道两侧都正确。新增一个网段意味着改动远端网关、本地网关，通常还要改动回程路径；漏掉任何一处都会产生看起来像应用缺陷的单向故障。应用团队看到超时，网络团队看到一条存在且表面上健康的路由。两个团队都没错，所以这个故障才这么难定位。

静态条目在下方路径消失后依然保持安装。除非平台提供跟踪，路由会继续指向不再转发的下一跳，流量不是切换而是悄然消失。你选择简单方案时，接受的就是这份沉默。

把跟踪方式写在每条路由旁边，注明它覆盖哪些故障，并把清单与隧道配置放在一起。否则下一次中断会由用户而不是网络发现，而那总是更昂贵的发现方式。

协议会通告新前缀、撤回不可达前缀，并在路径之间表达偏好。当多个站点或冗余隧道否则需要在每次变更时做协同改动，这确实有用。它也是协议会在最糟时刻给你惊喜的原因。上述每一个动作都是你本人没有做出的状态变化。

它会造出两个可能互相矛盾的状态。隧道可以是通的，而路由会话是断的；会话可以是通的，而它的通告漏掉了应用需要的网段。两者都像只工作一半的网络，而且从隧道状态页上都看不出来。

因此过滤与策略是设计的一部分，而不是事后补丁。什么都通告的协议迟早会通告错的东西，而错误前缀跑得比能纠正它的人更快。在启用第一条会话之前就写好过滤器，让第一次通告已经是刻意的。

按对端确定允许的前缀清单，并在入口强制实施，因为出方向的过滤器挡不住对端给你发默认路由。默认路由与聚合是这里昂贵的错误：它们能用一个看起来合法的学到的条目悄悄替换掉不相关的路径。除非设计确实需要，否则明确拒绝。

在第一条会话起来之前，把归属站点写在每个网络旁边，因为这份对应关系是过滤清单的来源，而不是文档上的点缀。没有它，改过滤器的人只能猜哪个站点该通告这个前缀。

两种协议之间的重分发是环路开始的地方，也是同一前缀带着无法干净比较的属性出现两次的地方。在具体需求逼迫之前，把重分发留在设计之外；如果必须有，就在边界处标记并过滤这些路由。

基于路由的隧道接口让动态路由更容易表达，因为隧道变成带路由的接口，而不是匹配选择器的策略。这并不能消除对端范围的问题：IPsec 选择器仍然必须允许你打算路由的流量。

无论选哪种，都要断开一条上联，确认流量会转移，或者按你记录的方式失败。只在两条路径都健康时测过的设计，等于根本没有测试过。顺便把检测时间量出来，因为你量到的数字就是用户会经历的数字。

然后独立确认回程路径，因为 VPN 上的非对称路由很常见，而且在有状态设备丢弃回应之前一直不可见。单向能通只证明了一半路径。

工作顺序：数前缀，决定故障该如何被检测，检查谁能运维这套协议，控制被通告的内容，然后端到端测一次中断。每一步都会产下一步需要的事实。