静态密钥的 OpenVPN 连接能服务多个客户端吗？

静态密钥模式恰好连接两个对端，这是它的设计，而不是谁忘了取消的限制。client-to-client 是服务器模式下的转发选项，所以把它加进 --secret 配置，并不会改变能连接多少个客户端。要决定的不是加哪个标志，而是部署需要点对点链路还是多客户端服务。如果多台设备必须各自独立连接，保护模式就会改变，每台设备都会获得一个身份。

两个对端、一个密钥、没有按客户端划分的状态：这个形态就是该模式的全部故事。

静态密钥模式的用途

在密钥模式下，两个对端共用一个密钥文件，这个密钥直接保护流量。没有握手、没有证书交换、也没有按客户端划分的会话，因为服务器意义上并不存在客户端，只有两个端点。

对于密钥轮换流程有文档记录的固定机器对，该模式仍然有用；OpenVPN 2.6 之所以把它标为弃用，正是因为 TLS 模式能以更好的特性覆盖这些场景。它做不到的是把一台正在连接的设备与另一台区分开，因为持有文件本身就是认证的全部故事。加入第三台设备就意味着与它共用同一把密钥，此后前两台便再也无法把它与自己区分开。

这就是为什么两对端的上限是结构性的，而不是可以更改的选项。

为什么 client-to-client 不是缺失的那一块

client-to-client 控制已连接的客户端能否通过服务器交换流量。它不接纳客户端、不分配身份，也不会创造出未配置的服务器模式；在静态密钥配置里，根本没有可供它管理的客户端列表。

另一种常见误解涉及 tls-crypt 或 tls-auth 材料。TLS 服务器可以在所有客户端之间共享这些密钥之一，因为它保护的是控制通道，而不是证明每个客户端是谁。TLS 模式下的共享控制通道密钥与共享静态数据密钥是不同的对象，尽管两者都以看起来相似的文件形式出现。

在两种模式之间做选择，归结为两个问题。是否需要不止一台设备独立连接，部署是否需要按设备吊销？两者都否定，静态密钥模式就可行；任一是肯定，就指向 TLS。不存在第三种选项能让第二个客户端在没有自己身份的情况下被接纳。

构建多客户端服务器

多客户端服务器需要 TLS 模式、服务器端证书以及按客户端划分的身份。服务器辅助工具会设置地址池和多客户端模式，但它不提供 TLS 配置、信任锚，也不提供让接纳有意义的客户端证书。

应当通过既有证书颁发机构为每台设备登记，而不是复制某个客户端的凭据。正是彼此不同的身份才使吊销、按客户端路由和有用的日志成为可能；一份共享的客户端证书会让这三者同时崩塌。

如果部署通过外部目录或第二因素认证用户，那套设计就保持原样。转向 TLS 服务器模式只决定对端在隧道层如何证明自己，并不规定账户后端。把两个决定分开，这样一方变化不会悄悄改变另一方。

然后就转发策略做出有意的决定。client-to-client 在用户空间服务器路径中启用客户端之间的流量，许多部署想要它，有些则绝不能有。它是策略开关，不是身份机制；开启它应当是因为设计需要，而不是因为某篇教程带上了它。

确认客户端真正相互独立

连接两个客户端，确认它们拿到不同地址，并在服务器日志中以不同身份出现。然后吊销其中一个，确认另一个仍能工作，这就是身份没有被共享的实战检验。

测试被允许的对端互访服务，以及一个应当保持阻断的服务。两次成功登录只能证明被接纳，并不能证明彼此隔离；当部署本应分隔用户组时，这个差别很关键。

最后，请从正在运行的配置里读取服务器模式，而不是凭记忆。带额外选项的静态密钥配置依然是点对点链路，只有正确的 TLS 服务器才是多个客户端真正互为独立对端的唯一安排。

如果日志显示每台设备都是同一个通用名，问题就不在模式。问题在登记流程。