云 VPN 需要 BGP：其他路由协议为何行不通

IPsec 安全联盟已经建立，隧道计数器在增长，但发往云上前缀的流量却消失了。运维人员随后尝试在客户路由器上启用 OSPF，期待邻居能够形成，结果什么也没有发生。隧道从来不是那块缺失的拼图：托管云 VPN 提供的是明确的路由契约，而在大型平台上这份契约就是 BGP。在会话建立并接受前缀之前，隧道只是一条没有目的的加密路径。

隧道已建立，路由却缺失

阶段 1 和阶段 2 完成，只能证明两端在保护方式上达成一致，并不能证明任何一方知道该把流量发往何处。它们是两台状态机，失效模式也彼此独立。

按顺序问三个问题：前缀是否被通告，是否被对端接受，是否为转发而安装。已通告又被过滤的前缀属于策略问题。从未通告的前缀属于会话或配置问题。已接受却未安装的前缀属于路由选择问题，每个答案都指向配置中的不同部分。

服务商实际提供的是什么

托管 VPN 网关不是一台无限制的路由器。服务商提供的是带有受支持对端地址、自治系统设置、前缀上限和明确故障行为的网关。这些表面就构成了产品。

Google Cloud 记录了 HA VPN 的动态 BGP 路由：Cloud Router 学习对端路由，并把符合条件的自定义动态路由提供给 VPC。AWS Site-to-Site VPN 记录了静态与动态路由之间的选择，并说明 BGP 存活检测有助于隧道故障切换，同时也为不支持 BGP 的设备提供健康检查。不应根据一方的产品名去推断另一方的行为。

实际后果是：先选择托管模式，再阅读受支持的参数。假定服务并不提供的邻接类型，这不是在客户路由器上能解决的配置问题。

隧道保护与可达性是两项不同的工作

IPsec 保护被选中进入隧道的流量。BGP 提供让前缀具备资格的可达性信息。隧道正常工作并不能证明预期前缀已通告、已接受或已安装。

设想一个分支通过两条合格隧道路径通告 10.42.0.0/16。撤掉一条可用路径，路由选择就可能改变，而没有人去修改每个工作负载的路由。检测、选路和应用恢复都不是瞬时的，也不在各次部署之间保持一致，因此故障切换测试必须观察整个过程，而不是只看第一个通过的报文。

当云上前缀不可达时，先检查会话状态和学习到的路由，再去碰加密。安全联盟已建立而身后没有路由，是这一症状最常见的形式。

OSPF 假设在哪里失效

在自管理设备上，于 IPsec 隧道内运行 OSPF、IS-IS 或其他协议完全可行，因为两端和转发设计都由你掌控。这一事实并不能说明只把 BGP 作为动态路由模式的托管服务。

如果拟议设计需要服务并不支持的邻接关系，就应当有意识地改变架构。可选方案包括在 VPC 内使用自管理设备、在服务支持的地方使用静态路由，或改用其他连接产品。只在客户路由器上配置协议，无法添加云侧并不存在的对端，也不会让前缀出现。

不要把某家厂商的答案搬到另一家厂商的网关上。同样的词，例如动态路由或隧道故障切换，可能描述不同的机制和不同的限制。

先读服务要求，再做设计

在写第一行配置之前，记下邻居地址、自治系统号、将要通告和接受的前缀、路由上限，以及隧道故障时的预期行为。这五项就是你要对照设计的契约。

然后按同样的顺序验证：会话建立、前缀收到、路由出现在 VPC 路由表中，以及到服务地址的真实流量。 在强制故障切换之后重做一遍，因为重新建立的会话可能带回不同的路由集合。如果设计依赖亚秒级收敛，就去做测量，而不是假设。

把服务契约与变更记录放在一起。日后有人问起隧道为什么不能运行 OSPF 时，答案是产品边界，而不是协议限制，记录里也应当这样写。