共享 VPN 账号：设备数量限制不等于客户端隔离

八条同时连接只是许可证页面上的一个数字，它完全没有说明这八台设备彼此之间能做什么。共享登录既可以配合按会话分发的密钥，也可以配合一台乐于把一个客户端的流量转发给另一个客户端的网关。错在把账号当成安全边界。不如分开问四个问题：买了什么、什么保护隧道、对等端之间允许通过什么、什么会拖垮本地链路。

连接额度究竟承诺了什么

设备上限统计的是提供商为一个订阅接受多少个会话。它是商业与运营层面的控制，而不是关于身份或隔离的声明。有些提供商会在一个账号下为每台设备签发独立证书；另一些则在每次连接时复用同一份凭据。差别在吊销时显现出来：独立凭据让你能单独切断一台设备，而共享凭据不给你这个选项。

在假设密钥分离之前，先读清提供商如何签发凭据。账号名称本身就什么都透露不了。

检查网关是否在客户端之间转发

对等端可达性是服务器端的决定。在 OpenVPN 上，相关开关除非出现在配置里否则并不存在，但现代数据面卸载改变了规则生效的位置。

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

没有该指令的配置把对等端流量留给主机防火墙，而防火墙仍可能放行。卸载生效时，隧道接口由内核而非用户态进程处理，所以要核对规则计数器，而不是相信配置文件。阻断隧道地址之间的转发流量可以隔离客户端，而不影响它们访问网关。从一个客户端向另一台上的服务发一次探测来确认，规则前后各做一次。

先保护会话，再谈对等端

隧道保护和对等端访问是两种不同的属性，强加密并不意味着隔离。在 TLS 模式下，每个客户端派生自己的会话密钥，因此即使网关转发，一个客户端也读不到另一个客户端的流量。旧的静态密钥方案在所有人之间共享一把密钥，所以在那里复用登录的后果严重得多。去查配置的模式，而不是营销页面，然后判断共享账号是否适合所涉及的数据。

每台主机上的服务认证仍然重要，因为隧道只能证明某个客户端到达了网络，并不能证明它应该到达某个特定守护进程。

本地 Wi-Fi 故障不是 VPN 被攻破

掉线证明的是本地链路失败，而不是有人攻破了隧道。干扰、DHCP 租约丢失和漫游切换都会结束会话，却不触及凭据或密文。把断连当作可用性发现，并把它与保密性和对等端访问的发现分开。在本地网络不可信的地方，要端到端保护流量，而不是只靠隧道。

把四个答案写下来：额度、密钥模型、对等端策略和本地链路依赖。这份记录能把关于共享账号的模糊担忧变成具体的控制措施。