AWS Client VPN 的规则应放在资源上，而不是子网上

员工需要访问 VPC 中的一个应用，且不能访问同一实例上的数据库监听器，于是有人为 VPN 终端节点新增第二个公有子网，并宣称需求已满足。子网位置改变的是路由和可用性，它并不授予或阻止任何一个端口。表达该需求的许可存在于目的地，即资源的安全组中，而 VPN 边界提供该规则所引用的句柄。

子网位置是路由，而不是授权

终端节点的网络关联位于何处，决定哪张路由表承载客户端流量、哪些可用区能在故障中存活。它完全没有说明该流量能到达哪个实例的哪个端口。关联到同一子网的两个客户端仍以相同的来源身份到达，资源无法用子网名称区分它们。

不妨从需求出发：谁调用、访问哪个资源、哪个服务端口、哪个方向。然后选择能在目的地表达这四件事的规则模型。这种思路通常会把多余的子网彻底从设计中移除。

对于与子网关联的 AWS Client VPN 终端节点，文档化的做法是具体的。把预期的安全组应用到终端节点的目标网络关联上，然后在该资源的安全组中，以该 Client VPN 组为来源放行所需流量。

具体来说，应用实例的安全组只允许来自关联组的应用端口，不允其他。AWS 的资源访问流程描述了这一关系，并且值得让终端节点关联的每个子网都保持同一套组策略，因为与另一个组残留的旧关联会在无声中扩大边界。

那条规则并不认证任何人。登录是另一层控制，到达资源的路径是第三层。三者都成立，请求才会到达。哪一层失效，就决定该用哪种修复；只有第一层才该改规则。

同一关联组背后的每个客户端，都以同一个安全组来源到达资源。两个角色不同的用户在该层面无法区分，无论组如何命名或打标签。Client VPN 的外部组授权按目标前缀为目录组或 SAML 组划定访问范围，这比资源角色更粗，应视为网络边界而非身份系统。

更细的区分属于应用。必须对大多数员工关闭的数据库监听器，与其指望组成员关系保持整洁，不如让它在该允许前缀上根本不可达，这样保护更彻底。

给组改名并不产生身份，按团队复制只会让需要审计的关联成倍增加。

自管的 EC2 VPN 网关、经过路由的检查设备与托管 Client VPN 是三条不同的数据包路径。要确定究竟哪个源地址能到达资源、途中是否发生地址转换，以及该服务在这条路径上支持哪些引用机制。

经中间设备转发流量，不会像实例间直连流量那样保留来源安全组引用。AWS 文档指出，这类设计可能需要改用合适的私有源地址或 CIDR，而不是组引用。托管 Client VPN 的流程并不能证明每个网关所挂的组都能当作转发数据包的通用身份令牌。

路径上只要多一次 NAT 跳转就足以打破假设，故障看起来就像一条存在却从不匹配的规则。

要读取挂在资源上的每个安全组，因为放行规则会叠加，一个组里的窄规则并不会取消另一个组里的宽规则。然后检查网络 ACL、主机防火墙和应用自身的授权，它们是各自会犯错的独立层次。

最后用同一个资源做一次被允许的请求和一次被刻意排除的请求。这一对能证明边界，而单次成功连接只能证明有东西是开着的。要确认路径、实际生效的来源和预期的服务端口，而不是终端节点所在的子网。

工作顺序：写下四部分需求，把组挂到关联上，把资源规则收窄到端口，验证一次允许和一次拒绝，然后才考虑因路由原因划分子网。