更大的 VPN 地址池不等于更大的会话上限

一个 /22 包含 1,024 个 IPv4 地址，而这个数字很容易被误当成容量。它说明该网段能支持多少项分配，而不是网关会接纳多少会话、又能转发多少流量。任何答案背后都有三种彼此独立的计数，它们以不同方式失效。把它们放在一起比较，才能把一次拒绝归到正确的那一项。

地址池、授权和工作负载用不同的单位、由不同的人分别计算。

地址池实际提供什么

从真实边界而不是掩码开始。子网拓扑决定服务器能分配多少地址，固定分配和保留会占用一部分，网络地址和广播地址不可用。/22 理论上提供 1,024 个，实际更少，这已足以打破人们预期的算式。与客户端必须访问的网络重叠，可能让看似宽裕的网段被排除。公布之前，先确认分配机制支持所提议的网段。

更大的地址池只消除一个约束。它不触碰接纳限额、许可或转发吞吐，而在路由与访问策略不变的情况下扩大子网，只会得到一个谁都到不了的网段。

许可证实际允许什么

平台支持的并发数与产品的授权额度是另外两个数字，二者常常并不相同。授权可能按用户、设备或并发会话计数，这些口径不能互换。供应商的订购指南显示各型号差别可以很大，因此旧数据表中的对等端数量不应带入新部署。请阅读适用于你实际运行的那项服务的协议。

按命名用户计数的许可证，不会仅因为地址池还有空位就接纳更多设备。

网关实际能承受什么

第三种计数是工作负载。估算这些会话合在一起产生的流量：报文速率、认证突发、加密开销，以及启用了哪些策略功能。交互式会话和大批量传输落在同一台设备上的方式完全不同。网关可能有空闲地址、也有许可额度可接纳，但预期负载已超出它的转发能力。忽视功能组合的容量规划，得出的数字只在一切关闭的实验室里成立。

出现拒绝时，正是查看网关为该次尝试记录了什么的时刻：分配事件、接纳决定，还是一次卡住的认证调用。这三种情况对应不同的修正，从客户端一侧猜测很少能选对。

先归因，再改动

有用的比较是在三种计数与观察到的故障之间进行。如果地址池已满，就扩容，并更新描述它的路由与策略。如果地址仍有剩余却拒绝接纳，约束在别处。如果会话被接纳而性能崩塌，问题在容量，而不在两个限额中的任何一个。

记录是哪一种计数耗尽、何时发生、之后又改变了什么。有了这份记录，下一次排查就不必再从子网掩码开始。

扩大地址池是一行改动，但要跟进三件事：路由、策略和重新测试。