跨可用区的 EC2：加 VPN 之前先查路由

在两台 EC2 之间安装 VPN 软件之前，先回答一个问题：它们是否在同一个 VPC 里？如果在，私有通路本来就已经存在，跨可用区部署并不会改变这一点。这种情形下大部分工作是确认每个子网实际使用的是哪张路由表，然后弄清故障究竟是不是路由问题。对这个具体问题，隧道通常是错误的答案。

检查 1：同一个 VPC 还是不同 VPC

VPC 是区域级的，跨越多个可用区；而每个子网只属于一个可用区。同一个 VPC 中不同可用区的两台实例，仍然处在同一个私有路由域内。

不同 VPC 不会仅仅因为共用一个区域或一个可用区标签就获得私有路由。那种情况需要受支持的连接，以及单独的路线与权限配置，属于另一项决策。

检查 2：子网路由表怎么说

用真实取值把布局写下来。一个位于 10.60.0.0/16 的 VPC，其子网为 10.60.1.0/24 和 10.60.2.0/24 时，会为实例 10.60.1.10 和 10.60.2.20 提供一条经由 VPC 本地路由的通路。

然后查看与两个子网都关联的路由表，而不只是你最先找到的那一张。更具体的检查路由或设备路由可能覆盖基线，本地路由的目标本身也可能在较新的配置中被替换。控制台里某处能看到一条本地路由，并不证明两个工作负载都在用它。

使用 VPC 实际分配的私有地址和名称。私有地址不一定以 10 开头，凭记忆编一个地址，正是把正常环境误判成故障的常见原因。

检查 3：路由问题还是授权问题

路由只把数据包送到目标的网络接口。目标的安全组仍须放行源与服务，源的出站规则必须允许该请求，任何网络 ACL 都必须双向放行，因为 ACL 是无状态的。

再往后还有来宾防火墙、监听绑定以及应用自身的身份。任何一层都可能拒绝一个路由已经完美送达的请求。

验收必须是真实的应用操作。ping 成功并不等于获得应用访问权限，也不能证明 TLS 名称与凭据正确；ping 被拒也不能断定所有私有服务都已下线。

检查 4：是否真的需要单独连接

VPN 仍可能是设计的一部分，但要有明确理由：把该 VPC 接入办公室、接纳笔记本，或满足叠加网络的要求。这个理由与普通的同 VPC 通信不同。

也要记住 VPC 不是什么。它不是家庭以太网段的延伸。依赖广播发现的应用另有需求需要评估。那是设计缺口，而不是路由错误。

检查 5：加密问题

私有地址与放行规则并不能说明应用层是否有加密保护。如果数据需要端到端保护，那来自服务真正支持的协议与身份模型。

在设计说明里把网络层与应用层的结论分开写，因为混在一起，评审最后就会声称一种没人实现的保护。

应当记录什么

记录两个子网 ID、各自关联的路由表、安全组引用，以及你测试过的应用操作。这就是四项事实，它们能解决日后关于这条通路的多数争论。

单靠可用区位置，永远不会告诉你该加一条 VPN，也永远解释不了某次私有请求为何失败。