VGW 还是 TGW？AWS Site-to-Site 的 IPsec 隧道在哪里终止

人们问 AWS Site-to-Site VPN 在哪里不再保护数据包，并期望一个答案：在网关处。真正有用的版本会说明是哪一个网关，因为虚拟私有网关和传输网关是两种不同的结构，挂载对象也不同；假设错一个，后面的评估就建立在一张并不存在的图上。请按顺序完成下面三项检查。每一项要么确认边界，要么告诉你上一个答案说的是另一种资源。

在评估任何东西之前先点名三个端点

这条路径的加密评审需要三样被点名的事物：客户网关、终止 IPsec 的 AWS VPN 目标，以及接收内层数据包的应用端点。在打开任何一页控制台之前，先把它们连同资源标识写下来，因为此后的每句话都是在说这三者之一。

客户网关是你的，其配置对你也可见。AWS 侧的目标是托管资源，错误就在于把它当成理所当然：VPN 连接既可以挂到虚拟私有网关，也可以直接挂到传输网关，两者并不互相蕴含。第三个端点正是人们跳过的那一个，而它是唯一能回答应用数据这个真正问题的端点。

检查 1：究竟是哪个网关终止了隧道

两种结构都受支持， Site-to-Site VPN 架构指南 并列描述了它们，所以要问 API，而不是问一张往往已经过时的图。对一条连接执行只读查询会返回 VPN 目标字段：

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

判别依据是 TransitGatewayId，而不是 VpnGatewayId。TransitGatewayId 为空的连接终止于独立的虚拟私有网关，而该字段已设置的连接终止于 传输网关的 VPN 挂载，这种情况下 VpnGatewayId 仍可能被填充，因为它可以指认该挂载的承载网关。先读 TGW 字段，再从挂载列表而不是字段名确认挂载类型，因为该传输网关上的 VPC 挂载并不是 VPN 挂载。在已连接的 VPC 里找到目的实例，并不能说明是哪条 VPN 挂载运送了这个数据包。

在那里时也检查隧道。连接为冗余携带两条 IPsec 隧道，而第二条隧道从未起来的连接，即便对加密边界毫无改变，在可用性上也是真实发现：

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

检查 2：内层数据包还带着什么

IPsec 终止后，AWS 按匹配的路由转发解封装后的数据包。从那一刻起，流量就是普通的 VPC 流量，VPN 的保护已经结束。这不是服务上的缺口；这就是边界的含义，而清单要做的就是把它讲清楚，而不是让“VPN 是加密的”顶替“数据是端到端加密的”。

现在看里面是什么。如果内层数据包是明文应用协议，那么在下游有任何东西加密它之前，不会有任何东西增加机密性。如果内层数据包本身就带着 TLS 会话，去掉外层 IPsec 对那个会话毫无影响：它一直受保护到自己的端点，无论那个端点在哪里。

常见的过度纠正，是断定网关背后的一切都暴露了。并非如此。服务传输、存储加密和应用 TLS 是条件各自独立的不同机制，每一项都要按它自己的条件来评估，而不能从 VPN 的形状去推断。一条显示 ACCEPT 的流日志只能证明路由通了，对机密性什么也没说，而这正是这份清单要防止的错误。

检查 3：网关背后是谁终止 TLS

跟随监听者，而不是地址。如果负载均衡器或代理终止 TLS，你客户端持有的连接就到此为止，代理再向后台开第二条连接，那条连接可能是明文，也可能是另一条信任链的 TLS。一个私有 IP 地址和一条匹配的路由，并不是关于第二条连接的证据。

从 VPC 内部测试你真正在意的那个端点，用应用实际使用的名字，而不是你曾经解析过一次的 IP：

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

对请求经过的每一跳都重复一次。如果面向客户端的名字与后台名字给出的答案不同，你就找到了 VPN 从未覆盖的那一段，而这正是要记录下来的发现。

把结果记成分段，而不是记成判决

这份清单的产出是一张小表，每段一行：客户网关到 AWS VPN 目标、网关到工作负载、工作负载到数据存储，以及中间任何代理跳。每一行说明它由什么保护，以及那种保护依赖什么。没有机制、没有端点的“已加密”不算一行。

然后按当初提出要求时的措辞来回答它。如果要求是数据在工作负载收到之前保持机密，那么 VPN 只满足第一段，其余各行需要应用传输、服务 TLS 或存储加密，并单独配置和验证。

把连接标识、隧道状态和证书主体留在记录里。半年后有人回看这套设计时，这三样东西能在几分钟内回答边界问题，而不必从一张图重新开始争论。