为什么 EC2 无法访问你的 AWS Client VPN 笔记本
Client VPN 会将 IPv4 客户端源地址转换为终端节点的网络接口。因此回程可以通信，而从 EC2 发起的新连接不行。
通过 AWS Client VPN 连接的笔记本电脑可以毫无问题地访问 EC2 上的应用。接着你反过来试，从 EC2 连接到分配给客户端的地址，连接却挂起或被拒绝。这种不对称很少是缺少安全组规则。在与 VPC 子网关联的 Client VPN 终端节点上，AWS 会把 IPv4 客户端源地址转换为终端节点的网络接口，因此不存在代表你笔记本的入站 VPC 地址。
先看抓包说明了什么
在客户端连接时于 EC2 主机上抓包，读取应用实际看到的源地址。如果它是 VPC 一侧的终端节点接口，而不是客户端池中的地址，那么在改动任何一条规则之前，转换关系就已经确认。
客户端池是分配范围，不是带返回路由的子网。大多数此类排查正是错在这个区别上。
解释这种不对称的转换
有三种流常被混为一谈，而人们测试的只有其中一种。
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN 组件说明明确指出，IPv4 客户端源地址会被转换为终端节点接口，这足以看出中间一行为什么没有可匹配的对象。
新连接需要路由、地址解析步骤和授权决定。别人会话中的转换状态这三者一个都不提供。
为什么回程应答不是新连接
TCP 应答会与已有表项匹配，所以回程路径完全不需要入站规则。EC2 主机发出的新 SYN 没有可匹配的表项，于是变成一次普通的出站尝试，目标地址是 VPC 不知道如何到达的。
这也正是把它描述成单向流量的误导之处。这些会话中的回程流量一直在流动。缺少路径的是发起这一侧。
为什么本该成功的会话仍然失败
安全组、网络 ACL 和笔记本自身的防火墙，对应该成功的连接都很重要。失败的 ping 提供的信息最少，因为 ICMP 策略常常与你关心的 TCP 策略分开。
这些规则要按转换后的源地址来写，而不是按客户端地址。绑定到网络上从不出现的地址的规则，是这种设计中最常见的自找故障。
当 VPC 确实必须主动发起对话时
如果某个服务必须通知工作站，就反转方向，让客户端保持一条持久的出站通道，由服务在这条通道上应答。如果整个远程网络必须能从 VPC 访问，应选择一种会发布其前缀和访问策略的架构，而不是假设 Client VPN 已经做到了。客户端到客户端访问是第三种更窄的情形，有它自己的路由和授权对象。这些都不是现有终端节点上的一个勾选框。
IPv4 解释的适用范围也要如实说明。当前 AWS 文档把不适用这种转换的 IPv6 区分开来，也区分了路由方式不同的其他连接模型。
分三个有标记的步骤测试：客户端打开一个被允许的会话，VPC 服务应答该会话，VPC 主机向客户端发起一个新会话。前两步成功而第三步失败，正是这种设计的预期形态，而不是需要用防火墙规则追查的缺陷。