很多企业在做多VPN方案选型或者扩容故障排查的时候，经常会遇到标称并发数差不多的两个VPN设备，实际可稳定接入的终端数量差出很多，甚至部分终端接入后直接出现业务断流，这时候如果只参考厂商标注的纸面VPN并发连接数量参数，很容易踩选型的坑，对比不同方案的并发能力时，必须逐项记录实际运行的核心指标，才能得到具备落地参考性的准确结果。
第一类指标：VPN网关侧的硬件与协议承载上限
很多运维人员对比参数的时候直接抄产品手册上的最大并发数，这是最常见的误区，你首先要现场记录的是当前VPN网关启用的加密协议类型，不同协议对硬件算力的占用完全不同，同一台设备跑IPsec协议的并发承载量和跑OpenVPN协议的承载量根本不在一个量级，脱离协议类型谈并发数没有任何实际意义。
你还要同步记录网关当前除了VPN服务之外，有没有同时开启防火墙规则、入侵检测、流量审计这类附加安全功能，很多厂商标注的VPN并发连接数量是关闭所有附加安全功能的裸跑数值，实际生产环境开启全量防护之后，可用并发数会出现明显的下降，这部分差异如果不记录，后续对比结果完全没有参考性。
第二类指标：单并发连接的资源占用阈值
很多运维人员排查并发不足的故障时，会发现网关CPU、内存占用还没到常规红线，新的VPN连接就已经被直接拒绝，这时候你要记录的是每一条VPN连接的实际资源分配规则，部分VPN系统会给每个接入终端预分配固定的内存缓存、会话表项配额，哪怕整体硬件资源还有剩余，预分配配额耗尽之后就不再允许新连接接入。
你还要记录并发连接的会话老化超时配置，很多旧的VPN系统不会自动清理异常断开的僵死会话，这些无效会话会长期占用并发名额，实际可用的有效并发数会远低于标称值，对比不同VPN方案的时候，必须把相同运行时长下的僵死会话数量单独记录，不能直接把总连接数当成有效并发数。
这里还要注意区分并发连接的定义边界，部分厂商的VPN并发连接数量统计的是同时在线的用户终端数，还有部分厂商统计的是终端和后端业务服务器建立的VPN隧道内的子连接数，同一个终端开10个业务页面就会被记成10个并发，这种统计口径的差异如果不提前记录对齐，后续的对比结果会完全失真。
第三类指标：并发场景下的连接可用性表现
你不能只统计成功接入VPN的连接数量，还要同步记录每新增一批并发连接时，新接入终端的连接成功率，部分VPN设备在接近标称并发上限的时候，会出现随机丢连接的情况，新发起的VPN接入请求有一定概率握手失败，这种半可用状态下的连接数，不能算成有效并发，必须单独记录标记。
你还要记录高并发场景下的VPN隧道连通稳定性，当接入的VPN连接数接近网关承载上限时，要抽样记录不同终端的隧道丢包、异常断连概率，部分设备在高负载下会主动踢掉低流量的VPN会话，给新连接腾出资源，这种隐性的连接抢占机制如果不记录，后续上线之后很容易出现无预警的业务中断。
第四类指标：跨节点集群的并发分配规则
如果是多节点部署的分布式VPN集群，你还要记录集群的并发连接数是全局统一调度的，还是每个节点独立限制的，部分集群方案的单节点并发上限很低，没有做全局负载均衡，哪怕总节点数加起来的标称并发很高，单节点跑满之后新连接还是会被拒绝，这部分规则必须在对比的时候单独标注。
最后还要记录VPN并发连接和内网其他网络服务的边界冲突情况，比如部分企业的内网核心交换机配置了会话表项上限，当VPN并发连接数量超过阈值之后，哪怕VPN网关本身还有富余资源，交换机也会直接丢弃新的隧道转发报文，这类网络链路层面的限制如果不单独记录，很容易把网络设备的瓶颈误判成VPN本身的并发能力不足。
做完所有指标的记录之后，你才能把不同VPN方案的并发能力放在同一基准下做对比，不会出现纸面参数好看实际用起来频繁出故障的问题，所有记录的指标都要标注对应的运行环境前提，避免后续不同场景下直接套用得出错误结论。
