AWS Client VPN 的客户端 CIDR 不能与 VPC 网段重叠

AWS Client VPN 端点会从你选择的地址池中分配客户端地址，而 AWS 会在创建端点之前就用目标网络校验该地址池。校验的重点不是某个子网看起来是否空闲，而是地址池是否与 VPC 网段重叠；今天是否有 EC2 实例占用这些地址，并不影响结论。重叠是网段层面的问题，与分配无关。

按顺序完成五项检查。第一项失败就停下来，因为后续步骤都无法弥补先前的决定。

重叠是网段判断，不是空闲地址判断

从 VPC 的 CIDR 出发，而不是从你打算关联的子网出发。172.20.0.0/22 的地址池落在 172.20.0.0/16 的 VPC 之内，即使没有任何子网占用它也会被拒绝，因为重叠是网段本身的属性，与当前分配无关。接着把端点要路由到的目标都加进来：对等 VPC、中转网关，以及通过站点到站点连接访问的本地网段。客户端可能需要访问的任何网段都应列入。

从账户里取这些信息，而不是凭记忆：aws ec2 describe-vpcs --query "Vpcs[].CidrBlock"，再加上你打算关联的子网的路由表条目。

地址池大小在动工前就定了

AWS 在 Client VPN 上只接受 /22 到 /12 之间的 IPv4 客户端地址池。/24 太小，/8 超出文档范围，两种错误都源于把地址池当成业务子网来规划。按预期的并发客户端加上余量来估算，再取整到允许的前缀。

在输入控制台之前先核对算术，因为前缀打错会悄悄改变地址池大小，没有任何提示：

python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"

它会打印地址总数、前缀长度，以及候选网段是否与 VPC 网段冲突；这比在变更窗口末尾推演子网掩码快得多。

解析器有独立的地址角色

VPC 解析器在 VPC 网段的基地址加二处应答，它不一定落在你所关联的子网内。认为解析器必须位于客户端地址池中，或围绕该地址去建子网，只会增加对象而不改变任何结果。真正重要的是端点带有客户端可应用的 DNS 设置，并且解析器可从隧道内访问。

把解析器、客户端地址池和关联子网作为三条独立条目写进地址规划。它们各自独立失效，其中一条正确并不说明另外两条。

创建时必须固定的四个字段

客户端 IPv4 CIDR 在创建时就固定。更换 DNS 服务器、添加关联、替换安全组、编辑授权规则、调整分离隧道路由都属于常规修改，没有一项会重命名地址池。这种不对称正是它值得评审的原因：便宜的项目是以后想改的，昂贵的项目是你一开始就要定下的。规划变更窗口之前，先读端点的描述。

在假定必须重建之前，先检查已部署的端点。aws ec2 describe-client-vpn-endpoints 会在一个响应里返回地址池、DNS、分离隧道标志和关联，通常足以排除重建。

替换端点，而不是给它打补丁

新端点就是新端点，不是迁移。既有会话不会转移过去，客户端配置指向另一个名称，你视为理所当然的每一项设置都得重建：服务器证书、身份验证、关联、路由、授权组、日志。用一个客户端对着必需的私有服务以及一个必须被拒绝的目标做验证，再逐步放开访问。任何跳过的东西之后都会变成支持工单。

在验证通过之前，让旧端点继续运行，并保留一条不依赖新端点的管理通道。

有一点边界需要说明：这里覆盖的是 IPv4 客户端地址池。Client VPN 上的双栈和 IPv6 流量设置遵循各自的地址模型，因此不要在没有阅读该模式文档的情况下套用这份清单。