Access Server 组 CIDR：成员地址还是资源网络

Access Server 的一个组里有两个字段接受 CIDR，乍看之下它们像同一类输入：一个描述分配给 VPN 成员的地址，另一个描述这些成员可以到达的网络。填错字段不会报错，正是这一点让这个错误代价高昂。前者改变隧道的地址规划，后者决定允许访问哪些目标，两者互不蕴含。还有第三类对象常被混进这两个字段，即分支网关后面的子网，它不属于任何字段。

同样的语法，不同的问题

先问这个值在命名什么。成员地址 CIDR 回答的是接入的客户端会拿到哪些内部地址，分配机制在任何流量开始前就会使用它。资源 CIDR 回答的是这个组可以使用哪些目标，访问规则在评估数据包时使用它。一个是地址池的定义，另一个是许可。

混淆的后果正好相反。把目标 LAN 粘进地址池字段，可能发放该 LAN 上已存在的地址，造成地址重复的行为；也可能移动地址池，让所有按旧网段编写的防火墙规则悄然失效。把地址池粘进访问规则则什么也换不来，因为那里没有任何目标。两个错误的表现形式一样：隧道起来了，但总有什么不对。

分配：成员地址空间

地址池不能与成员可达的任何 LAN 重叠，也不能与部署里的其他 VPN 池重叠。这是规划约束，不是产品设置：当两个站点都为成员使用 10.90.40.0/24 时，一个站点的成员不经过转换就无法路由到另一个，任何访问规则都修不好。

分配模式同样重要。动态池给每个成员下一个空闲地址，按用户的静态分配则把它固定住。当防火墙规则或监控要指向具体成员时，静态分配正是你需要的，它也让地址规划的变化可见：被固定的地址要么仍在新池里，要么已经不在。在这个字段做任何改动前后，读一下某个已连接成员的隧道地址。

许可：目标网络应当写在访问规则里

可达性由访问规则表达，规则里写明组或用户、目标网络或服务，以及访问方式。最后这一部分是大多数半成品配置出问题的地方：一条规则可以把流量路由到目标，也可以对它做 NAT，两者对网络的要求不同。被路由的路径要求目标一侧知道如何把流量送回 VPN 池，而 NAT 路径则把成员藏在目标已经信任的地址后面。Access Server 组文档把组的网络与组的访问规则分开，而标签在各版本之间移动过。

允许的目标仍然需要一条可用的路径。规则放行，路由送达，回程回应，主机上的服务接受。四件事、四个排查点，而只有第一件在访问规则里。许可显示为绿色但 traceroute 不通，通常说明目标网关缺少回程路由，而不是规则写错了。

第三类对象：网关后面的分支子网

声明某个客户端拥有一个子网是关于站点的路由声明，既不是地址分配，也不是许可。用 Access Server 的术语说，这是对连接网络的受支持网关配置，它之所以存在，是因为分支路由器可以宣告它身后的 LAN。成员仍然从地址池拿地址，也仍然需要一条访问规则才能使用那个分支 LAN。

把三者分开在复核时会有回报。把分支子网记成组的成员地址空间，在截图里看着是对的，却会破坏组内所有人的分配。只记在访问规则里的同一子网则给了访问权却没有归属声明，于是回程流量无处可去。在设计中让每个对象占自己的一列，这个错误就不可能发生。

怎样判断你在看哪一个

把标签和它的邻居一起读。紧挨分配模式、池大小或按用户覆盖的字段属于分配。紧挨组选择器、服务或端口、路由方式的字段属于许可。版本会改名，但邻居大致还在原地，所以旧截图上的措辞是很差的导航指南。

然后用一个成员而不是整组去验证：它的有效组、被分配的隧道地址，以及授权预期目标的那条规则。按顺序确认路由、NAT 或被路由的路径、回程流量和服务许可，只改与已证实的不一致相符的那个字段。之后也要把分配和许可的记录分开，免得后来改动地址池被读成组可达范围的变化。