报告里什么才算一次成功的 VPN 登录

三份关于同一个 VPN 的报告可能互相矛盾，却没有任何一份是错的，因为每一份对“登录成功”的理解都不同。一份统计到达服务器的连接，另一份统计认证环节接受的身份证，第三份统计完成初始化的会话。在收集数据之前先选定其中一种，这就是指标与争论之间的差别。

有用的问题不是哪种定义在一般情况下正确，而是读者准备依据哪一种结果采取行动。

三种不同的事件共用一个名称

服务器在握手完成的那一刻就接受传输连接，而这发生在任何凭据被提交之前。这个事件只说明端口可以到达、网络路径通畅，却完全不能说明是谁连了上来。认证是更靠后的一步，可能失败，也可能对一个从未获准进入网络的身份证同样成功。

初始化发生在认证之后，而一条完成了初始化的隧道可能空转一整天。只有应用层的请求才能证明用户真正抵达了他想要的东西。这些阶段层层嵌套，所以最外层那一环的计数永远大于最内层的计数。事件的先后顺序中，没有任何东西能证明用户产出了成果，只能证明每一道门依次打开了。

产品文档通常会把各种状态明确命名。OpenVPN 的 管理接口文档 把 TCP 连接、认证结果和初始化完成区分开来，而这正是报告需要的区分。一个标为 connected 的状态，并不能证明此后文件共享或数据库操作真的成功。

统计会话、身份证还是请求

先定单位，再定数字。按会话统计回答的是服务被使用了多少次，按身份证统计回答的是出现了多少个不同账户，按请求统计回答的是完成了多少工作。厂商的统计口径也不一样，用用户衡量的授权无法与用会话衡量的图表相比。选错单位，容量规划就会按错误的量来定尺寸。

重连正是会话数悄悄膨胀的地方。一个每隔几分钟就掉线重连的客户端，会给同一个人留下几十条会话记录，因此把会话当成人数来统计的报告，恰恰会在可靠性最差的条件下高估使用量。把规则写下来：重连之后的新会话单独计数，或者在规定的时间窗内视为上一段会话的延续。

地址是最弱的可用身份。隧道地址几分钟后就可能分配给另一个用户，两个用户也可能通过地址转换共用一个地址。应当附上认证事件里的账户标识，而不是从日志中的地址去推断某个人。

用一个真实的日子检验这一定义

取一天日志，用三种方式统计同一批流量。如果三个数字很接近，说明对你来说定义也许并不那么重要；如果相差很多倍，报告就必须写明用的是哪一种。

journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Initialization Sequence Completed"
journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Peer Connection Initiated"
awk '/VERIFY OK/ {print $NF}' /var/log/openvpn-server.log | sort -u | wc -l

在已知发生过故障的那一天跑同样的抽取，比较形状而不是总量。上行链路抖动的那天，连接事件应该出现尖峰，不同账户只小幅上升；如果不是这样，这个计数器很可能量的并不是报告所声称的东西。

把查询本身和结果放在一起。任何人都能复现一个有记录的过滤条件，而没有过滤条件的数字无法审计。

报告事件究竟证明了什么

失败的尝试应当单独归类，而不是被折进任何一边。失败包括输错的密码、配置过期的客户端和刻意的探测，这三者的应对方式并不相同。失败既不是入侵成功的证据，也不是无害的证据。

按照事件支撑的强度来写结论：这个账户在这个时间窗内、从这个来源，向这个服务完成了认证，并且会话到达了初始化。至于用户随后做了什么，需要应用侧的记录，而不是更多的隧道数据。

当报告送到要做授权、容量或安全决策的人手里时，把定义放在第一行，而不是脚注。定义本身就是结论，数字只有放在定义之内才有意义。