AWS Client VPN：登录成功却访问不到子网

客户端显示 Connected，证书也没问题，内网页面却照样超时。这种落差几乎从来不是认证问题。AWS Client VPN 的授权和登录是两件事，常见原因有两个：组值与身份提供方实际发送的值不一致，以及更具体的按目标分流规则压过了宽泛规则。只要知道该看哪里，这两点在端点配置里都能查出来。

登录成功了，规则却没匹配上

认证回答的是用户是谁。授权规则回答的则是这个身份能到达哪些网段。用户可能过了第一关却卡在第二关，而客户端除了保持连接、让每个请求都超时之外，几乎不会给你更多信息。

先确认端点有没有一条授权规则，其目标包含出问题的那个地址。如果没有匹配的规则，连接本身的行为是正确的，缺的是策略。

在 Active Directory 里，access-group 字段存的是组的 SID，而不是显示名。用 SAML 联合时，它存的是配置的 SAML 组属性实际携带的组 ID 或组名。值要从 assertion 或目录查询里复制，不要照抄 wiki 页面。

IAM 组是另一个控制面。有权管理 Client VPN 端点，并不等于 IAM 组就是用户的 VPN 组；把 IAM 组名贴进 access-group 字段，也不会变成 AD 的 SID 或 SAML 属性值。

另一个目录里名字相似的组证明不了任何事。要查端点用的认证方式，以及该用户在同一套系统里的组成员关系或 assertion。

授权按最长前缀匹配来评估，全目标规则是最后评估的，而不是最先。给 Engineering 加一条 10.46.0.0/16，再给所有人加一条 0.0.0.0/0，Engineering 之外的用户依然无法通过这条宽规则访问 10.46.20.10。

问题就出在这里：所谓的修复可能出错。删掉那条窄规则能恢复该用户的访问，但同时会把这个子网开放给宽规则覆盖的每一个身份。删任何东西之前，先画出组到网段的对照表，并写清哪些组应该访问哪个范围。这些规则只做允许；没有拒绝条目可以让你从宽泛的允许里切出一个例外。

改动还需要重新建立连接才能公平评估。改完规则后重连客户端，然后再测一次。

规则匹配不等于路由可达。端点还需要关联子网和目标对应的路由表条目，目标资源的安全组也必须放行流量。回程流量和 DNS 同样要通。

用一个本该成功的用户和一个本该被排除的用户分别测试。两人都能登录，但只有一人能到子网，这个差异才是你想要的证据。

如果 IP 地址通、主机名不通，先看解析器，别急着动授权。如果没有路由覆盖该地址，就修关联或路由表。如果包到了而服务拒绝，下一个该查的就是那个服务的策略。把授权矩阵放宽到所有用户，只会掩盖究竟哪一层真的坏了。

结单之前，把身份来源、准确的组值、目标网段，以及承载流量的那条路由记录下来。有了这份记录，下一次再接到的连上了但访问不了，就能变成两分钟的比对，而不是又一轮猜测。