AWS Client VPN 的认证：IAM 权限不是登录方式

给用户授予创建或描述 AWS Client VPN 终端节点的权限，并不等于让他能连接到该终端节点。这是两种不同的身份：IAM 管理的是 AWS API 调用，而终端节点只接受其上配置的客户端认证方式。因此，用户可能拥有很宽的控制台权限，却拿不出 VPN 客户端能够出示的任何凭据。先确定终端节点信任哪种方式，再决定完整隧道是不是你所授予访问的正确形态。

API 身份不是隧道身份

当有人说「IAM 角色已经附加了，为什么 VPN 还是连不上」，答案通常是连接流程中没有任何一步会读取这个角色。客户端出示的是证书、AD 用户名和密码，或 SAML 断言。终端节点验证其中一种，然后分配地址。

IAM 依然重要，只是出现在更晚、更别处：创建终端节点、关联子网、发布路由、编写授权规则，这些都是 API 操作。请把这些权限限定在真正需要的运维人员手里，而不是让每个用户都能改写终端节点的访问规则。

从终端节点支持的方式中挑选

AWS Client VPN 接受基于证书的相互认证、Active Directory 认证，以及基于 SAML 的联合认证。无论选择哪种客户端方式，都需要服务器证书；而组合多种方式的配置要求两者都成功，而不是其中之一。

证书部署成本最低，但在规模化时最容易出错，因为每个用户都需要一份凭据，每次离职都需要一次吊销。目录认证把这套生命周期交给现有系统。联合认证把它交给身份提供商，并给客户端增加一个浏览器步骤。

在调试客户端之前，先读终端节点自身的配置。如果相互认证与基于用户的方式同时启用，那么持有有效证书但没有目录账户的客户端仍然会失败，而错误看起来往往只是普通的握手问题。

联合认证不是传递访问密钥

SAML 配置不会把 IAM 访问密钥或代入角色的令牌送进隧道。身份提供商认证此人，返回一条断言，终端节点在你配置的信任关系下接受它。由此得到的会话是 VPN 会话，而不是 AWS API 会话。

这一区别决定了谁能排查什么。IdP 的问题会在隧道存在之前就以浏览器或客户端错误的形式出现，而隧道的问题则在断言成功之后才出现。打开任何一个控制台之前，先问清楚自己看到的是哪一种。

登录之后，路由与授权仍然起决定作用

认证只给会话一个地址，并不给会话一个目的地。终端节点的路由告诉客户端把流量发往哪些子网，授权规则决定哪些用户能够到达其中哪些子网，而安全组加上目标自身的权限决定其余部分。

这就是为什么认证成功的用户仍然可能连不上数据库。请按这个顺序检查子网的路由表关联、用户所在组的授权规则，以及目标上的安全组，因为三者产生的是不同形态的超时。

针对单个私有数据库，与端口转发做比较

如果真正的任务是一条获批的连接通往一个私有数据库，那么完整网络隧道是选择而不是必需。AWS Systems Manager Session Manager 可以通过 IAM 打开一条通往受管节点的端口转发会话，由该节点访问私有网络中的数据库。用户始终拿不到 VPC 地址。受管节点成为唯一能到达数据库端口的宿主机，这通常正是安全评审所要求的。此时用户需要的是本地客户端和会话命令，而不是 VPN 配置文件。

取舍在于范围与前提条件之间。端口转发需要受管节点上的 SSM 代理、从该节点到数据库的网络可达性、用户机器上的 Session Manager 插件，以及启动该特定会话的权限。它不是通往每个子网的路，也不会像隧道那样承载任意协议。

无论哪种方式，都保留数据库自身的身份。TLS 校验和数据库认证不会因为路径由 IAM 授权而消失，一次获批的会话也完全不代表用户能读哪些表。

按范围与生命周期来选择：当许多用户需要许多目的地、而你能运行证书或目录生命周期时，选隧道；当少数人只需要一个服务、而你不愿发放网络地址时，选转发会话。无论哪种方式，都把认证方式、授权规则和数据库登录记录为三件独立的事实，因为它们各自独立失败。