RADIUS 计费与登录成功的区别：各自证明了什么

每个 VPN 计费讨论都会把两个问题混在一起：这个用户是否被允许连接，以及他实际做了什么。前者由认证回答。后者需要由开始、更新和结束组成的计费记录。登录成功只证明前者，对后者只字未提，所以一套能正常工作的 RADIUS 认证仍然可能产出空的用量报表。

两个不同的问题

认证决定连接能否开始，并返回裁决以及地址池或组之类的属性。计费则记录随后发生的服务，将其写成绑定到同一个会话的事件序列。

两者走同一套协议，通常也发往同一台服务器，正因如此，人们才误以为其一蕴含其二。

访问请求里没有任何字段携带会话时长，Stop 记录也不会重新判定该用户是否本应被放行。把二者当作两份独立契约，集成工作就变得清晰：一条路径需要的是裁决，另一条需要的是包含开始、中间和结束的生命周期。

三类记录各自提供什么

Start 记录开启会话，Interim-Update 在会话打开期间报告活动，Stop 将其关闭。三类记录都携带会话标识符，接收方才能把它们归到同一个服务事件上。

这个标识符是三者之间唯一可靠的纽带，因为同一个用户名可能先后或并行持有多条会话。存储设计应围绕它展开，而不是围绕账号名。

确认收到记录与妥善存储是两回事。计费规范禁止在记录无法写入时作出确认，因此响应确实说明接收方承担了责任。但它并不说明后续的报表任务、仪表盘或计费导出正确消费了它。

为什么用户名不是会话

同一个人早上用笔记本、下午用手机连接，两条会话携带同一个账号名。对于只有 Start 而没有配对 Stop 的情况，靠查名字再挑最老的开启行是关不掉的。

正是这种捷径，让用量报表出现不可能成立的时长。

要把网络接入服务器的身份与会话标识符一并保留，因为两台服务器可能在不同上下文中分配相同的值，仅按标识符合并会把互不相关的会话粘在一起。会话非正常结束时，对账策略必须决定如何关闭它，这个决定属于设计，而不是每月一次的手工改库。

PAM 适合与不适合的地方

OpenVPN 的认证插件会调用 PAM 的认证与账号管理阶段。账号阶段检查的是资格；它的名字并不意味着用量计费，插件也不会驱动 PAM 的会话开启与关闭钩子。

有些 PAM RADIUS 模块能通过这些会话钩子发送计费记录，而这只在应用真正调用钩子时才生效。

因此，把这样的模块加进认证栈并不会产生断线事件。若需要完整生命周期，应选择真正拥有它的集成：某个插件或受支持的构建，能在连接状态变化时发出 Start、Interim-Update 和 Stop。还要检查它的维护状态，以及接收方不可用时的既定行为，因为一个静默丢弃记录的插件，看起来与从未发送过记录的插件一模一样。计费规范定义了集成必须遵守的记录语义。

一次能证明契约的验收运行

先测正常的连接与断开，再测同一账号下的重连，最后测不主动断开就消失的客户端。

从生成、确认到落库，完整跟踪一个会话标识符，并核对计数器的方向、单位与接口。没有标注的字节数事后无从审计。

最后确认：服务器不得不因超时关闭的会话，会被报表以它能理解的方式呈现。只覆盖优雅断开的契约，恰恰在最需要它的日子里失效。