按角色扩展 VPN 会话，再检查故障余量

你加了第二台网关，控制台显示两个健康成员，会话上限却几乎不动，因为没有任何东西告诉客户端如何到达新设备。扩展 VPN 服务是先后两个决定：这种连接类型由哪种机制来分配客户端，以及最严重的单点损失之后还剩多少容量。顺序反过来，就会得到一个看起来冗余、却在最需要时恰好失效的设计。先在控制台确认，再做算术。

让机制与会话类型相匹配

远程用户、站点间对端和常开设备隧道并不是可以互换的会话。为其中一类构建的分发功能通常会在协商过程中重定向客户端，而这对已经持有固定地址和静态配置的对端毫无意义。

Cisco 的 ASA 高可用性指南 把三种能力区分开：远程访问 VPN 负载均衡、有状态故障转移和站点间集群。只有第一种会把符合条件的客户端从组条目转到成员上，LAN 到 LAN 的连接不在此分发范围内。通用 TCP 负载均衡器无法替代协议自身的重定向步骤，因为隧道握手并不是代理可以改写的普通 HTTP。实际结果就是：均衡器接受了连接，客户端却仍然建不起隧道。

在订购第二台设备之前，把功能清单对照你的会话类型读一遍。许可证一行和机制一行是两条独立记录，一条并不意味另一条。

算一遍例子，而不是猜

假设三台网关在你们批准的工作负载下各验证到 800 条并发隧道，合计 2,400。高峰时段目标 1,650 看上去很宽裕，直到损失一台，剩下的两台就必须在硬性的 1,600 之上撑住 1,650。设计已经失败，任何故障转移调优都修不好算术。

把目标定在让幸存集合仍能满足的水平：对三成员组来说，就是待在总量的三分之二以下。这个比例是算术的性质，不是任何产品的性质，所以成员验证数字一变就重新计算。把授权数、文档上限和自己实测的数字放在三列里，因为三者很少一致，而最小的那个说了算。第四列记录观察到的高峰峰值，能让计划在第一个月后依然诚实。

把重连风暴也纳入预算，而不只看稳态

故障成员上的会话不会悄悄出现在别处。取决于机制，它们要么带着状态转移，要么从头重新协商，要么等应用按自己的时间表重试。

一分钟内几千个客户端同时重试，和稳定的 1,650 是两回事，认证服务器会最先感受到。还要检查地址池空间，因为重定向并不查询它：无法分配地址的成员仍会接受客户端，然后丢掉它的流量。

拿着地址池和路由去验证容量

验证是只读操作，能在维护窗口打开前抓住大多数设计错误。收集每台成员的地址池、活动会话数以及回到客户端子网的路由，再逐项对照计划。地址池耗尽和回程路由缺失，都会表现为客户端认证成功之后丢流量。

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

这些读取要在正常高峰时段对每台成员执行，而不是在清闲时段。报告有会话却没有空闲地址的成员，不管许可证怎么写，都已经到了实际极限。把固件版本记在每份输出旁边，因为命令名称会随版本变化。

在非工作时间有意演练一次损失，并记录演练期间幸存成员报告了什么。接受重定向却没有地址池空间的成员会表现为分配失败，这是加带宽永远修不好的。把验证过的数字连同日期存在计划旁边，让下一次容量评审从证据开始，而不是从许可证表格开始。即使数字与计划一致，也要把那次演练的结果加到同一页上。