接受 VPC 远程访问需要拒绝测试

远程访问的验收是一张预期结果的表，而不是一张能用的页面截图。 对每个组，写下哪些操作应当成功、哪些应当失败，然后在受控的时间窗口里用专门的测试身份把两者都跑一遍。 证明边界的是拒绝那一部分；登录成功只能证明隧道存在。 这一切都能在已经选定的 VPN 产品上完成。

测试使用独立的账号，并给它们加上标记，以免有人把测试身份当成真实例外。

把边界写成预期结果

从角色出发，而不是从组件出发：谁需要哪项服务、从哪里访问、用哪个身份。 举一个示例 VPC：一个组需要通过 HTTPS 访问预发布环境，另一个组需要生产数据库，第三个更小的组负责管理网关本身。 每一行都要写一条预期允许和一条预期拒绝，包括本不该可用的相邻服务和相邻账号。 这张表就是验收标准，不执行测试的人也能审阅它。

把数据库登录与网络路径分开测试。 可达的 TCP 端口不应让未获批的数据库账号登录成功，VPN 成员身份也不应创建云 IAM 角色或授予管理 API 访问权限。 这是三个相互独立的控制，它们会各自独立地失效。

路由不是授权

路由让路径成为可能；它并不授予权限。 扣住一条路由，只是对目的地强制执行限制的弱替代，因为客户端总能自己添加一条路由。 真正决定的是安全组、数据库授权以及应用自身的授权。 当某个测试意外成功时，先看目的地的策略，而不是你原本打算给客户端的那张路由表。

这也是拒绝测试针对服务端的原因：这些结果无法通过修改客户端来改变。

控制实际看到的是哪个源地址？

控制所评估的源地址取决于网关架构。 托管在 EC2 上的网关可能转发一个被路由的地址池、转换成自己的地址，或在 NAT 之后呈现另一个地址；托管的 Client VPN 会关联到子网并遵循自己的模型。 安全组和网络 ACL 看到的是经过处理之后到达的地址。 用错误的源假设去检查规则，是常见的一种做法：建起的边界看起来正确，却放行了错误的流量。

把每个结果与最小的有用事件关联起来：身份与会话、资源、操作、时间以及判定。 CloudTrail 的 API 调用、VPC 流日志和 VPN 会话日志回答的是不同的问题，任何单独一项都不是应用的审计。

撤销身份，再测一次

把撤销也纳入同一张表。 先删掉一个测试身份，确认新会话被拒绝，然后单独确认现有会话会怎么处理，因为这是两种不同的行为，负责人也不同。 检查网关重启或更换之后会发生什么，避免手工添加的例外悄悄消失或变得更宽。 只维持到下一次部署的边界，不是边界。

这些都不能取代打补丁、恢复或凭据生命周期管理的工作。 它让一个更窄的承诺变得可衡量：该来的人用上该用的服务，而旁边的路由、账号和管理面留在授权之外。

把这张表和部署放在一起，网关变动时重新跑一遍。 测试很便宜；测试背后的假设并不便宜。