我遇到了一个非常奇怪的问题，即我与 Wireguard 的连接。当我通过 Wifi 使用它时，可以连接到我服务器上的 VPN 服务，并且可以发送数据包，这些数据包将由公开服务接收（我检查了日志）。但我没有得到客户端服务的答复。在一种情况下，我得到了部分答复，其中我收到了 302 重定向。客户端尝试遵循它，然后永远等待。除此之外，连接正在使用移动热点（测试 Android 和 IOS）并通过有线连接工作！然后我从服务器获得答案。这让它变得更加奇怪......
让我向你展示我的设置：
服务器配置：
[Interface]
ListenPort = 51820
PrivateKey = [PrivKey]
[Peer]
PublicKey = [PubKey]
AllowedIPs = 10.10.10.3/32
客户端配置
[Interface]
PrivateKey = [PrivKey]
ListenPort = 21841
Address = 10.10.10.3/32
DNS = 10.1.1.100
[Peer]
PublicKey = [PubKey]
AllowedIPs = 10.1.1.0/24, 10.10.10.0/24
Endpoint = [ServerIP]:51820
服务器上设置的路线（我没有手动设置任何路线）
10.1.1.0/24 dev br-0bf5fcc52e62 proto kernel scope link src 10.1.1.1
10.10.10.3 dev wg0 scope link
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.64.0/20 dev br-d5796e116857 proto kernel scope link src 192.168.64.1
192.168.80.0/20 dev br-3ccf8b8eb318 proto kernel scope link src 192.168.80.1
当我尝试通过 curl () 访问 10.1.1.11:8090 上的服务时，curl -v -L 10.1.1.11:8090我将收到此信息：
❯ curl -v -L 10.1.1.11:8090
* Trying 10.1.1.11...
* TCP_NODELAY set
* Connected to 10.1.1.11 (10.1.1.11) port 8090 (#0)
> GET / HTTP/1.1
> Host: 10.1.1.11:8090
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 302
< X-ASEN: SEN-18244413
< X-Confluence-Request-Time: 1599383330642
< Set-Cookie: JSESSIONID=4FB43A370B32EFEE708BD04A9D999883; Path=/; HttpOnly
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Content-Security-Policy: frame-ancestors 'self'
< Location: /login.action?os_destination=%2Findex.action&permissionViolation=true
< Content-Type: text/html;charset=UTF-8
< Content-Length: 0
< Date: Sun, 06 Sep 2020 09:08:50 GMT
<
* Connection #0 to host 10.1.1.11 left intact
* Issue another request to this URL: 'http://10.1.1.11:8090/login.action?os_destination=%2Findex.action&permissionViolation=true'
* Found bundle for host 10.1.1.11: 0x7f8768504fd0 [can pipeline]
* Could pipeline, but not asked to!
* Re-using existing connection! (#0) with host 10.1.1.11
* Connected to 10.1.1.11 (10.1.1.11) port 8090 (#0)
> GET /login.action?os_destination=%2Findex.action&permissionViolation=true HTTP/1.1
> Host: 10.1.1.11:8090
> User-Agent: curl/7.64.1
> Accept: */*
>
^C
最后一行显示我需要按 Ctrl+C 退出，因为 curl 挂在那里。
另一个服务响应如下（或不响应）：
❯ curl -v -L 10.1.1.10:8080
* Trying 10.1.1.10...
* TCP_NODELAY set
* Connected to 10.1.1.10 (10.1.1.10) port 8080 (#0)
> GET / HTTP/1.1
> Host: 10.1.1.10:8080
> User-Agent: curl/7.64.1
> Accept: */*
>
这里 curl 也永远等待着..
如果我使用移动热点或有线连接，则一切都会正常。所以这不应该是 NAT 问题。我也在PersistentKeepalive两个客户端上测试了该选项，但没有成功。
该行为也与操作系统无关。因为我用 OSX 和 Windows 客户端进行了测试。
所以总的来说，wifi 连接似乎是问题所在，或者导致问题的原因。我不知道原因是什么。有人能帮忙吗？