两台设备共用一个 OpenVPN 证书：重连循环

每隔半分钟就重新上线的隧道，通常不是加密算法或 MTU 的问题。这是一个身份被用了两次。服务端看到熟悉的通用名，把新会话当作最新会话，较旧的那台设备则发现自己已被取代。在客户端看来，这像是一次空闲超时加一次重启，所以排查往往会从错误的地方开始。

从重启间隔入手

间隔本身就是第一条线索。与 ping-restart 窗口吻合的稳定节奏，指向被替换的会话而不是链路故障，因为链路故障很少如此规律。记下两次重启之间的准确间隔，以及客户端日志里的原因行。超时之后接着重启，与握手失败讲的是两个不同的故事。

对照第二台设备，检查重启是从什么时候开始的。新笔记本、手机，或复制到备用机器上的配置文件，通常就是触发点，而时间往往与某人完成设置的那一天吻合。

把间隔和原因写下来。两者都是证据，而且收集成本很低。

读一读服务端关于第二次登录说了什么

在自己掌控的服务端上，日志会点出这个通用名，并显示有第二个连接进来。没有 duplicate-cn 时，这次进入会替换同名的现有会话，日志消息通常也会直说。启用 duplicate-cn 后，两个会话并存，症状随之改变：客户端都还连着，但共用同一套按客户端区分的设置和同一个吊销决定。要把两条记录放在一起读，因为替换只有在顺序中才看得见。

在托管服务上，你可能完全没有服务端日志。这时线索是时间：一条本来稳定的隧道，每当另一台机器连上就掉线，而客户端日志里除超时之外没有别的。

要比较两份配置文件里的证书与密钥块，而不只是远端主机名。复制出来的配置文件通常只有文件名不同。

在服务端把身份拆开

通过为该服务端签名的 CA，为每台设备各签发一本证书。用 Easy-RSA 就意味着每台设备有各自的客户端名，配置文件再由那本证书及其私钥生成。通用名于是成了设备身份，而这正是服务端所缺的。请按设备命名，而不是按人来命名，这样换机时就会产生新名字。

共享的控制通道密钥是另一回事。tls-crypt 或 tls-auth 为所有客户端保护控制通道，本来就是供共享的。它不是客户端身份，换掉它并不能修复重复的证书。

把证书、私钥以及任何按客户端区分的配置文件放在同一个通用名之下，否则下一次连接时映射就会断掉。这里一旦不一致，就会得到一个认证通过却收不到任何东西的客户端。

拆分之后让地址与设置保持一致

固定地址会引入第二种冲突方式。如果服务端通过 ifconfig-pool-persist 或按客户端的文件来分配地址，这些记录仍然指向旧名字。即便证书已经拆开，两台设备仍可能拿到同一个隧道地址，而那种故障看起来与最初的循环并不相同。

在更新证书的同时更新映射，然后重新连接两台设备，比较各自分到的地址。重复地址表现为间歇性丢包，而不是一次干净的重连。

需要按设备区分的设置，要通过那台设备自己的文件下发，而不是共享模板。共享模板也会让下一次重复更难被发现。

把旧身份妥善退役

硬件退役或丢失时，应当吊销证书，而不是从旧机器上删掉配置文件。吊销会生成新的 CRL，而服务端需要该文件出现在 crl-verify 指向的位置。该指令生效时，CRL 缺失或不可读会让服务端拒绝每一个客户端，所以每次更新后都要用一个已知账号试一次。

维护一份清单，把每本证书对应到某个人或某台设备，并记下签发与吊销日期。这份清单不必读文件名就能回答谁还有访问权，也能阻止下一份被复制的配置重新启动循环。