分支机构重连风暴：strongSwan 的准入限制

观察一次链路故障后分支机构重新上线的情形，网关会看到平日里绝不会出现的景象：几十台笔记本同时从同一个公网地址涌入。每台都是合法设备，每台都发起一次尚未完成的 IKE 交换。这波洪峰能否成功，取决于一些与服务器能承载多少员工毫无关系的限制。洪峰很短，而这正是准入门径当初设计要承受的负载。

跟踪一台笔记本重新接入网络的过程

客户端发出初始请求后等待，在交换完成之前，网关会为这次尝试保留准入状态。同一地址后面的其他设备在第一个仍在等待时到达，它们排在一个按地址而非按用户计数的限制后面。从外部看，症状是少数用户连上了，而更大的一群人超时。

这一连串过程里没有任何故障。准入门径只是在做它被配置要做的事。

把半开工作当作独立资源来统计

strongSwan 把两类对象分开：完全建立的关联，以及仍在连接或等待处理的尝试。阻塞阈值针对归属同一对端地址的半开关联，而 cookie 阈值则全局生效并按地址生效。这些计数器保护守护进程不被未认证的工作耗尽，而这正是重连风暴的形态。这些状态都不会出现在 已建立隧道的列表 中。

把两者读成员工会话上限，正是导致一次性调高所有数值的错误。一台承载四百条已建立隧道的服务器，并不自动能够吸收四百个同时到达的首包，因为这两类开销落在不同的地方。

认证延迟决定每次尝试在半开计数里停留多久。后端响应慢，即便到达速率不高，也会把短促的洪峰变成长长的队列。

swanctl --stats
swanctl --list-sas | grep -c ESTABLISHED

修改之前先读懂准入设置

在形成判断之前，先找出运行中的守护进程实际加载了哪些数值。配置常常分散在主文件和按插件存放片段的目录里，因此在一处设定的值可能在另一处被覆盖。下面的搜索会列出所有提到这些设置的文件。

然后再判断哪个数值太小。如果单个地址合法地代表整间办公室，那么按地址的阻塞阈值就是必须容纳这种集中的值。全局 cookie 阈值保护守护进程免受更大范围的洪水，不应因为某一个站点重连就放宽。把这个按地址的值与你实际拥有的最大站点作比较。

保持 cookie 机制启用。cookie 让客户端在守护进程真正为交换投入工作之前，证明自己能在所声称的地址接收报文；关闭它并不是中性的容量升级。只有在有实测到达速率和明确认证预算的前提下，才提高阈值。

grep -rn -E 'block_threshold|cookie_threshold' /etc/strongswan.conf /etc/strongswan.d/
swanctl --stats | grep -i half

为回归做规划，而不只是稳态

只统计已建立会话的可用性目标描述的是一个安静的下午，而不是一次恢复。应当反过来问：共享网络事件之后，目标人群如何回归，准入门径能否吸收这种形态。

在受管机群中错开重连，往往比扩大限制更便宜，因为它消除的是人为洪峰，而不是长期为它付费。把半开状态和准入事件与成功建立一起监控，并把成功数持平而半开数上升视为预警，而不是趣闻。

这些设置的厂商参考资料是 strongswan.conf 文档，其中列出了各项计数器以及引入按地址 cookie 阈值的版本。请阅读你所安装版本对应的章节，而不是最新页面，因为默认值会随版本变化。