Wireguard一直在一个客户端上生成一个新的键盘。

Question

客户端2成功地维护了一个有线连接。客户端1重复创建/销毁键盘。

这两个配置文件在客户端2 (Android，移动连接)上都能很好地工作，即使它们以前在客户机1 (Windows，云VM)上也不能正常工作。

我重新启动了wg0接口。对wireguard服务器的常量pings不会显示来自客户端1的任何问题，我只是无法加载任何我怀疑的页面，因为键盘不断变化。没有其他设备使用客户端1的配置文件。一个奇怪的事情是，两个键盘是如何在同一时间创建的，这很可能是它们被永远摧毁的原因。

如何解决导致键盘需要重新创建如此频繁的原因？

2022-07-25 07:21:25.332: TUN Keypair 11为同伴1创建

2022-07-25 07:21:25.332: TUN将保活数据包发送给对等方1 (:51820)

2022-07-25 07:21:25.518: TUN从同伴1处接收保活包(:51820)

2022-07-25 07:21:41.666: TUN接受同伴1的握手启动(:51820)

2022-07-25 07:21:41.666: TUN向同伴1发送握手响应(:51820)

2022-07-25 07:21:41.667: TUN Keypair 10为同伴1销毁

2022-07-25 07:21:41.667: TUN Keypair 12为同伴1创建

2022-07-25 07:21:41.882: TUN从同伴1处接收保活包(:51820)

2022-07-25 07:22:28.060: TUN从同伴1处接收保活包(:51820)

2022-07-25 07:22:52.214: TUN重试与同伴1握手(:51820)，因为15秒后我们停止了回音。

2022-07-25 07:22:52.214: TUN向同伴1发送握手启动(:51820)

2022-07-25 07:22:52.385: TUN接受同伴1的握手响应(:51820)

2022-07-25 07:22:52.385: TUN Keypair 11为同伴1销毁

2022-07-25 07:22:52.385: TUN Keypair 13为同伴1创建

2022-07-25 07:22:52.385: TUN将保活数据包发送给对等方1 (:51820)

2022-07-25 07:22:52.571: TUN从对等方1(：51820)接收保持活着的数据包()

Answer 1

我偶然发现了这个确切的问题(或者说非常相似？)这就是对我起作用的原因：

如果客户无法完成握手--我建议尝试重新生成密钥--如下所示：

https://serverfault.com/questions/1040165/wireguard-not-completing-handshake

然而，这并没有解决我的问题。

第一，验证wireguard服务器日志中报告的WAN IP地址是否与客户端的地址匹配。我的在最后一个八重奏中被淘汰了--这很奇怪。由于我的客户端托管在ISP网络上，它共享一个公用IP地址，用于许多软管--可能是UDP数据包最终出现在其他一些有线设备上(？猜测)--所以我无法准确地判断，因为我对ISP内部网络几乎没有可见性。

第二，如果客户端的广域网IP (您可以像curl -s ipinfo.io/ip一样验证，或者通过在google中输入“什么是我的IP”)不匹配--您可能希望更改客户端wg0.conf，以便在与ListenPort = 51820不同的端口上侦听--我对其进行了如下调整：

root@wg-client2:~# cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = ###MODERATED###
Address = ###MODERATED###/24
ListenPort = 51810

此客户端conf更改不需要任何服务器更改。

我在服务器和客户端都做了wg-quick down wg0 && wg-quick up wg0，然后建立了通信。(可能只需要重新启动客户端)。

去检查线缆克恩。日志：

1. echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control

1. dmesg -wT | grep wireguard

将所有客户端转储到服务器上：wg show all dump

关于有线日志记录的好文章：https://www.procustodibus.com/blog/2021/03/wireguard-logs/

Answer 2

从来没有更新过，但问题是数据包在主机路径的某个地方被碎片化。我相信在他们的一端，因为它工作了多年，然后突然停止。我在wireguard配置中减少了MTU，问题就解决了。

以防其他人遇到类似的..。