复制的 WireGuard 配置：为什么两台设备都出问题

隧道在笔记本电脑上工作正常，于是配置文件被复制到手机和平板，现在三台设备的握手时断时续。没有输错任何内容，服务器配置也没有改过。WireGuard 配置不是可以多台设备共用的带密码账户；它是一对密钥，只有公钥那一半才标识一个对端。复制文件就等于复制身份，所以服务器现在试图为一群自称同一个身份的设备维持同一条端点关系。从服务器角度看，根本看不到第二台设备，只看到一个地址不断漂移的对端。

先从每台设备上的握手日志看起

在改动任何东西之前，先在每台设备上打开客户端，记录最后一次握手时间和当前端点。配置健康时，设备在使用期间这些值保持稳定；身份重复时，时间戳会交替出现，而服务器记录的端点可能指向另一台设备，而不是持有配置的那台。这种交替就是特征，也解释了为什么症状看起来像连接不稳，而不是配置错误。设备并没有坏，它们是在互相打断。

要在设备本身上读取，这样每条观察都能对应到具体机器。从支持对话里复制来的时间戳会失去这种对应，事后几乎没什么用。

确认两台设备是否共用同一个身份

比较公钥，绝不要比较私钥。公钥由私钥推导而来，所以包含同一私钥的两个配置会生成同一公钥，对服务器来说无法区分。如果两台设备报告同一公钥，问题就已经确定，再怎么调 keepalive 也没用。两个不同密钥却握手不稳，指向的是完全不同的方向，所以必须先做比较，再动手改。

wg show wg0 public-key
wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

这些命令只打印公开材料和计数器，而支持沟通需要的也就这些。服务器上一条对端记录只有一个公钥，而端点却在两个网络之间不断移动，这正是复制的预期结果，因为来自新来源的已认证数据包会更新流量发送的目标。这种行为其实是协议按设计工作，所以特别容易被误认为网络故障。

按正确方式再配一个身份

在需要的那台设备上生成新的密钥对，然后把得到的公钥作为独立对端加到服务器上，并配上它自己的允许地址。私钥应当在设备上生成并留在设备上；在别处生成再粘贴进来的密钥至少多经过了一个地方，这段旅程如今也成了信任故事的一部分。

umask 077
wg genkey > newdevice.key
wg pubkey < newdevice.key

服务器一侧需要公钥，以及一份不与原设备冲突的允许地址分配。保留旧隧道地址却出示新密钥的配置，会造出一个服务器可能接受、随后又路由错误的对端，这比握手被拒更隐蔽。要在连接之前检查地址分配，而不是在第一次莫名其妙的丢包之后。

在不破坏原件的前提下退掉副本

新身份工作正常后，把复制的那份配置从原设备的周边移除，而不是删掉原件仍在使用的服务器记录。如果副本可能已经外泄，那就立刻吊销并重新签发；方便不是让共享秘密继续流通的理由。

真正支持一份订阅多台设备的托管服务会明确告知，并从自己的界面签发独立凭据。手动复制一份配置从来不是那种模式，哪怕服务的品牌暗示设备数量不限。

把两台设备分开测，也放在一起测

先单独验证每台设备：握手、传输计数器在走，以及只有隧道能到达的目标。然后同时运行两台，观察服务器眼中的端点；两个不同的密钥应当产生两条稳定的对端记录，而不是一条跳来跳去的记录。

把新的公钥和部署记录放在一起，并写清哪台设备持有哪一份。没有这份清单，下一个复制配置的人会重犯同样的错误，交替出现的握手又会被算到网络头上。