共享 VPN 账户的会话上限：为什么偏偏是一台设备掉线

你在已经登录手机的那个账户里再加一台笔记本，一分钟后手机的隧道断了。或者新设备始终连不上，客户端最后给出的不是超时，而是一条策略消息。两种情况里网络都是好的，判断发生在网络之上。共享登录只对应一个身份，而多数 VPN 服务统计的就是这个身份，不是你手上有几台设备。我的顺序是从客户端的屏幕往外走，因为它通常会告诉你哪一层拒绝了你。

先读客户端提示，再动网络

三种失败长得像，其实不是一回事。超时说明你的包哪儿也没到。TLS 或证书错误说明对端回了话，但握手没成。认证拒绝或策略拒绝说明网关看过你的信息之后把它拒了。只有第三种属于会话上限这类故事，所以先把它确认下来。

OpenVPN 客户端把关键行留在日志面板里。滚到最后一次连接尝试，而不是后面那段重试循环，找 AUTH_FAILED 或者服务端发回的原因文本。客户端常常只报一句笼统的拒绝、不给解释，所以下一步要看服务器，而不是改客户端设置。厂商自带应用更糟：设备数超限的提示有用，但两秒就崩掉的连接是策略决定，不是密码错了。不管哪种情况，记下设备名和准确时间；运维能在一秒内把这组信息对上访问记录。

在服务器记账的地方清点会话

真正算数的计数器在网关上。服务器以 --status 启动时，OpenVPN 会写一份状态文件，列出每个已连接客户端的通用名、真实地址和流量计数。

cat /var/log/openvpn-status.log
# or query the management socket directly
echo "status 2" | socat - UNIX-CONNECT:/run/openvpn/server.sock

同一个通用名下的两行，就是同一张证书下的两个活会话。默认情况下 OpenVPN 不会同时留住两个：没有 --duplicate-cn 时，第二张使用同一证书的连接会顶掉第一条，旧设备丢掉它的隧道。这种顶替就是身份上限的特征。随机丢包不会挑在另一台设备出现的同一刻，客客气气地只断开一台。

WireGuard 没有可以查的会话表。wg show wg0 会打印各个对端和它们最近一次握手，而每台登记过的设备都是一个带自己密钥的对端。那里的共享账户其实就是一份复制到多台机器的配置文件，限制来自分发这份配置的东西：厂商门户、席位数量，或者一条绑在你公网地址上的规则。自己运维网关的话，OpenVPN 2.6 手册里写明了服务端选项。

把一条消息背后的四种上限拆开

共享账户的工单，多数是四种准入决定之一。客户端分不出来，但哪台设备失败的规律能。

同一个身份，第二条连接。新设备能用了，旧设备在同一刻断掉。这是网关或账户系统在执行的按身份并发规则。什么都没坏，服务只是照它写的策略在做。

套餐里的席位或设备数。前几台设备连着，再添的那台被拒，其余照旧。改客户端之前先看厂商的设备列表，因为许可证上限没法从客户端这边修好。

绑在你公网地址上的限制。同一个家用路由器后面的两台笔记本都失败，而同一个登录从手机热点能用。把第二台设备挪到别的网络试试。如果那边能连，你看到的是按地址的规则或 NAT 规则，不是账户数。

整个服务器的上限。网关上的所有人都在同一个高峰时段失败，包括昨天还好好的账户。OpenVPN 的 --max-clients 就是这个行为，和你登记的设备毫无关系。

先清掉残留会话，再考虑加购席位

一次收尾很差的会话可能还占着位置。RADIUS 计费在会话开始时写下一条记录，会话停止时再把它关上；客户端消失时停止报文永远不到，服务器就把这条会话留着，直到过渡更新或超时到期。在 FreeRADIUS 网关上能看到这些没有关闭的记录：

SELECT username, acctsessionid, acctstarttime
FROM radacct WHERE acctstoptime IS NULL;

开始时间很旧、又没有流量的开放记录，属于已经离开的设备。先通过运维控制台或一条断连请求把它关掉，再下结论说限制是真的。Wi-Fi 交棒给移动网络时手机会重连，而一台笔记本可能系统里跑着一条隧道、厂商应用里还跑一条，这就算一台机器上的两个会话。

不要再让协同工作的设备共用一个身份

长久的修法是结构性的。给每台设备发一张通用名唯一的证书，或者一个独立账户，并记下由谁、哪台机器持有。OpenVPN 上这意味着每台设备一张客户端证书，除非你就要抢占式行为，否则 --duplicate-cn 保持关闭；WireGuard 上则是每台设备一对密钥，在那儿生成，绝不复制。

为了绕开设备上限而克隆配置，会把吊销机制弄坏：吊销一份副本会切断所有共用它的设备，日志也再说不出哪台机器做了什么。如果这是商业限制，诚实的修法是加一个席位；如果是内部政策，请申请第二个拥有同等访问权限的身份。

按固定顺序验证

每次都用同样的方法测，结果才有意义。

• 在每台设备上退出登录，确认服务器的活动列表是空的；清不掉的条目是残留会话，不是客户端缺陷。
• 一台一台连上去，在每次连接之间观察列表。
• 如果两台必须同时跑，确认两行的身份不同，而且都在保持握手新鲜。
• 从 Wi-Fi 切到移动网络之后再测一遍，因为重连可能生成第二条记录。

如果新设备连上时旧设备还是掉，说明网关在执行一条按身份的规则，而你没拿到豁免。把设备名、时间戳和活动会话列表带给运维，这能把含糊的抱怨变成他们答得上的政策问题。