Google HA VPN 连接 Cisco 路由器：先规划对端资源
在配置 Cisco 路由器之前，先命名 Google 的两个接口、对端资源、IKEv2 约定和每个 BGP 会话，然后选择单对端还是双对端。
在 Cisco 到 Google 的 HA VPN 中，第一个决定不是使用哪个加密配置文件，而是一个本地设备还是两个设备来终止隧道。Google 的 HA VPN 网关有两个接口，每个接口都期待一条对应的对端隧道。无论你有没有两台路由器，这都会给你两条隧道，差别在于单个电源或一次软件升级是否会让整个设计瘫痪。
决定在于一个还是两个对端设备
依据三个条件选择布局：你能否接受本地故障点、是否必须使用两个云接口，以及工作负载能容忍多少重新收敛。如果三者中任何一项是硬性要求，那么两个对端设备才是诚实的答案。
在打开控制台之前就定下这一点，因为答案会改变工作表必须描述多少条隧道和 BGP 会话。
先写工作表，再敲命令
工作表有五列，每一列都需要一个负责人：
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
外部对端资源描述你在 Google Cloud 内部的接口，创建它并不会配置 Cisco 路由器。这种不对称会让那些以为云控制台是两端真相来源的人感到意外。它是 Google 应当预期什么的声明，而路由器仍然必须与之匹配。Google 的 对等网关指南 把这一声明映射到你仍需完成的隧道、BGP、防火墙和 IKE 工作。
如果某一行没有负责人，切换期间值班的人就会把它填上。
把三种地址角色分开
公共对端地址承载外层 IPsec 交换。内层 BGP 对属于运行在其上的受保护逻辑连接。通告的 LAN 和 VPC 前缀描述该连接背后的工作负载。把虚拟机的内部地址复制到外部对端字段会混淆前两种角色，故障看起来像协商问题，而不是数据录入错误。
规划两条对应的对端隧道，每个 HA VPN 接口一条。同时使用两个云接口本身并不能消除本地故障点，因为两条隧道仍可能落在同一台机箱上。
在工作表中每个取值旁写下地址角色。这一个习惯就能避免大部分混淆。
把工作表落实到 Cisco 版本
从受支持的对端文档或与你平台匹配的 Google 配置模板入手，然后逐项核对每个占位符与工作表。把 IKEv2 身份验证、ESP 提议、PFS 以及隧道和路由模型放在一起检查，因为其中一项不匹配通常表现为另一项不匹配。用实际平台和软件版本判断哪些受支持，因为 Classic VPN 配方是另一个起点。
让共享密钥远离截图、工单附件和支持笔记。粘贴到案例评论里的预共享密钥是凭据泄露，不是排障产物。
如果模板和工作表不一致，停下来在纸面上解决。设备不会替你仲裁。
用各自的证据验收每条隧道
HA VPN 需要 BGP 会话，成功的 IKE 协商 只建立第一阶段。内层会话必须建立，预期的前缀必须被通告和接受，并且在负载流量开始前必须存在可用路由和防火墙权限。把这一切记成一盏绿灯，会掩盖究竟哪个阶段失败了。
按隧道记录验收证据：协商的安全关联、BGP 邻居状态、预期学习到的前缀，以及预期的工作负载路径。然后做一次受控的故障与恢复检查，因为从未故障过的隧道，其恢复路径也未经检验。
下次设计变更时这份记录可以复用，这正是互操作与丢失假设的命令片段之间的区别。