Cloud VPN 的 BGP 地址在隧道里面，不在网卡上

打开该 VPN 的 Cloud Router 页面，一个地址落在 169.254.0.0/16 里的 BGP 会话正盯着你。最自然的反应是把这个地址放到 VM 的某处，然后等会话起来。这个反应在某个具体层面上是错的：这对地址属于 IPsec 隧道建立的逻辑链路，而不属于机器普通的网络接口。你在网卡上加任何东西，都不会让隧道承载 BGP。

应当沿协议栈往下追踪这对地址，而不是把它加到主机上。

从控制台显示这对地址的地方开始

会话页面会列出 Cloud Router 的 BGP 地址和对端地址，在 IPv4 的 HA VPN 里两者都是 link-local。它们旁边是终结隧道的对外网关地址。这是不同的对象：link-local 对在内部，网关地址在外部，而且在其他任何东西生效之前必须先可路由。

打开配置文件之前先把这三个都写下来，因为把它们混在一起就是整个故障模式。

往下走到承载它的那条隧道

只有当两个网关之间存在 IPsec 安全关联时，这对 link-local 地址才有意义。在 Google 一侧，HA VPN 隧道在两个接口上建立它；在你这一侧，它是双方协商出来的结果。先用 swanctl --list-sas 检查数据关联，并记录哪条隧道在哪个接口上处于活动状态，因为死隧道上的健康 BGP 会话不可能存在，而带着满怀希望的配置的死隧道却是常态。

BGP 报文是内部 IP 流量。外部网络永远看不到它，所以没有任何交换机需要把两个地址放在同一个 VLAN 上。

现在把 Linux 一侧配置得与之一致

选择受支持的隧道设计，让设计来决定内部地址。对于基于路由的接口，路由条目和协商出的流量选择器必须一致，因为光有接口名什么也不允许。把 BIRD 指向内部本地地址和 Cloud Router 的内部地址，从会话页面设置 AS 号，并在受保护路径内允许 TCP 179。把通往远端外部地址的路由留在物理上行链路上，这样隧道就不会抓走自己的传输。

自己路由自己的隧道是一条带握手的环路，它会像防火墙问题一样持续一个小时。

按顺序检查每个阶段，而不是一次看全部

逐段走过去：安全关联已建立、能从隧道地址访问内部对端、BGP 会话已建立、前缀已被接受，然后才是工作负载前缀真正被使用。birdc show protocols 只回答第三个问题，别的一概不回答，这就是人们过早宣布胜利的原因。

建立起来的邻居并不保证双方都通告了你需要的前缀，也不保证那些路由以优先方式安装。

如果会话已经建立而流量仍然走错路，就把通告的前缀与路由表对这些前缀的处理结果做对比。别处一条更具体的路由，或者对另一条路径的偏好，只会给你一个能工作的 BGP 会话，却没有任何有用的转发。

在把这套做法用到 Router Appliance 之前先停一下

Network Connectivity Center Router Appliance 是另一种接入模型。它的 Cloud Router 对端使用来自 VPC 与子网布局的内部地址，而不是 HA VPN 的 link-local 对。如果真正的目标是用一台路由 VM 跑 BGP，请遵循那个产品的接口要求，而不是照抄一个 link-local 会话。

link-local 的作用域仍然是它字面上的意思。逻辑隧道提供了这个邻接关系，它并不授权把任意的 link-local 目的地跨 VPC 路由。