求帮忙分析一个 Wireguard 组网网速慢的问题

119 天前
 JerryYuan

请教组网大佬一个疑难杂症.

背景

我在城市 A 工作,购买了一台 NAS,上边下载了一些影视剧.为了让在城市 B 的父母也能看这些资源,选择用 Wireguard 进行组网,同时我还有个部署在腾讯云上的博客,利用这台机器的公网 IP 作为救援狗洞,将这台机器也纳入了整个 Wireguard 组网中.拓扑图如下: 建立了如图中所示的 5 条 Wireguard 隧道:

  1. 网关 A-网关 B 互联:走 IPv6 直连,主要用于父母访问我这边的 NAS
  2. 网关 A-本人手机互联:走 IPv6 直连,主要用于本人在外回城访问 NAS 上的 Grafana 监控等
  3. 网关 A-腾讯云 CVM 互联:走 IPv4 直连,主要用于本人在城市 A 的家里访问博客后台(不对公网开放 22 等端口)
  4. 腾讯云 CVM-本人手机互联:走 IPv4 直连,主要用于本人在外访问博客后台
  5. 网关 B 互联-腾讯云 CVM 互联:走 IPv4 直连,主要用于隧道 1 不可用时,对网关 B 进行紧急救援,一般只有一些心跳流量

网关 A,网关 B,腾讯云 CVM 拥有三个不同的内网网段,已经实现拓扑图中任意两点之间的互访(路由表等)

问题发现

大概从 2~3 天前开始,我发现我从手机 A 走隧道②过网关 A 访问家里的 NAS 下行速率(NAS→手机)只剩 0.1Mbps 了,但上行速度还算正常(手机→NAS),还能有 10Mbps.平时这条链路只有我查看 Grafana 监控的流量,一般我也不怎么看 NAS 上的视频,因此不存在非常大的流量.

问题检查过程

1. 初步定性

因为用的都是移动网络,对移动关于大流量封禁和 UDP QoS 有所耳闻,初步分析认为是因为隧道①中父母看视频产生了过多的流量(但实际上也就每周末有稍微集中一些的上传),导致自己遭遇了相同的限速问题,于是第一时间尝试验证各个链路的可用性.

2.验证隧道①速度

在网关 A 上部署 iperf3 服务器,网关 B 直接测试速率,得到以下结果:

root@OpenWrt:~# iperf3 -c <网关 A 地址>
Connecting to host <网关 A 地址>, port 5201
[  5] local <网关 B 地址> port 44024 connected to <网关 A 地址> port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.50 MBytes  2.10 Mbits/sec    0             sender
[  5]   0.00-10.03  sec  2.38 MBytes  1.99 Mbits/sec                  receiver

iperf Done.
root@OpenWrt:~# iperf3 -c <网关 A 地址> -R
Connecting to host <网关 A 地址>, port 5201
Reverse mode, remote host <网关 A 地址> is sending
[  5] local <网关 B 地址> port 51104 connected to <网关 A 地址> port 5201
[ ID] Interval           Transfer     Bitrate
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.03  sec  49.9 MBytes  41.7 Mbits/sec  1182             sender
[  5]   0.00-10.00  sec  47.2 MBytes  39.6 Mbits/sec                  receiver

iperf Done.

结论: 城市 B 网关->城市 A 网关 上行 2Mbps 左右 下行 40Mbps 左右(符合城市 B/城市 A 上行带宽).也就是说,实际上城市 A 网关的上行并没有被限制。

3.验证隧道③速率

验证完 1 的链路后,还是不放心,又验证了隧道③的速率:

root@CVM:~# iperf3 -c <网关 A 地址>
Connecting to host <网关 A 地址>, port 5201
[  5] local <CVM 地址> port 37276 connected to <网关 A 地址> port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
...    
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  21.7 MBytes  18.2 Mbits/sec  670             sender
[  5]   0.00-10.00  sec  21.1 MBytes  17.7 Mbits/sec                  receiver

iperf Done.
root@CVM:~# iperf3 -c <网关 A 地址> -R
Connecting to host <网关 A 地址>, port 5201
Reverse mode, remote host <网关 A 地址> is sending
[  5] local <CVM 地址> port 37304 connected to <网关 A 地址> port 5201
[ ID] Interval           Transfer     Bitrate
...              
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  57.8 MBytes  48.4 Mbits/sec  1934             sender
[  5]   0.00-10.00  sec  55.3 MBytes  46.4 Mbits/sec                  receiver

iperf Done.

结论: 腾讯云 CVM->城市 A 网关 上行 20Mbps 左右 下行 40Mbps,也是符合我云服务器和城市 A 的上行带宽.到这里基本可以确定城市 A 网关应该是没有什么限速的问题存在.

4.验证隧道②的速率

本人的手机 A 是一台 Android 手机,安装了 Termux,可以执行一些 Linux 命令,遂尝试开 Wireguard 的情况下使用 iperf3 对的网关 A 进行测速.

~ $ iperf3 -c <网关 A 地址>
Connecting to host <网关 A 地址>, port 5201
[  5] local <手机内网地址> port 39652 connected to <网关 A 地址> port 5201
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  4.00 MBytes  3.36 Mbits/sec    2            sender
[  5]   0.00-10.60  sec  2.62 MBytes  2.08 Mbits/sec                  receiver

iperf Done.
~ $ iperf3 -c <网关 A 地址> -R
Connecting to host <网关 A 地址>, port 5201
Reverse mode, remote host <网关 A 地址> is sending
[  5] local <手机内网地址> port 39726 connected to <网关 A 地址> port 5201
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec  0.00 Bytes  0.00 bits/sec   70            sender
[  5]   0.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  receiver

iperf Done.

结论: 这里手机->城市 A 网关的速度已经不正常了,上行还能有 2Mbps,下行就风狂重试几乎测不出速度了.至此怀疑是手机流量的问题,计划再测试一下手机->CVM 云服务器的速度.

5.验证隧道④的速率

在腾讯云 CVM 上开 iperf 服务器,使用手机连接,测试得到如下结果:

v~ $ iperf3 -c <CVM 内网地址>
Connecting to host <CVM 内网地址>, port 5201
[  5] local <手机内网地址> port 41036 connected to <CVM 内网地址> port 5201
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  5.50 MBytes  4.61 Mbits/sec    0            sender
[  5]   0.00-21.37  sec  1.84 MBytes   724 Kbits/sec                  receiver

iperf Done.
~ $ iperf3 -c <CVM 内网地址> -R
Connecting to host <CVM 内网地址>, port 5201
Reverse mode, remote host <CVM 内网地址> is sending
[  5] local <手机内网地址> port 41156 connected to <CVM 内网地址> port 5201
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.07  sec  69.6 KBytes  56.6 Kbits/sec   72            sender
[  5]   0.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  receiver

iperf Done.

结论: 手机->CVM 云服务器速率也是不正常的,上行只有 4Mbps 不到,时常丢包丢到不到 1Mbps.目前基本怀疑是流量网络的问题.

6.确认蜂窝网络流量的问题

测试到这里基本觉得就是移动蜂窝网络搞了什么新策略,把我 wireguard 的 UDP 包给 QOS 了.但是还不死心,又尝试了下面这个拓扑: 这里我将手机上的配置文件传到笔记本上,然后笔记本走 USB 共享手机的网络,建立隧道②和隧道④,然后重新用 iperf3 测试了以下隧道的速率,于是这里就出现了很神奇的事情:


C:\Downloads\iperf-3.19-win64>iperf3 -c <网关 A 地址>
Connecting to host <网关 A 地址>, port 5201
[  5] local <手机内网地址> port 6224 connected to <网关 A 地址> port 5201
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.01  sec  1.50 MBytes  1.26 Mbits/sec                  sender
[  5]   0.00-10.33  sec  1.38 MBytes  1.12 Mbits/sec                  receiver

iperf Done.

C:\Downloads\iperf-3.19-win64>iperf3 -c <网关 A 地址> -R
Connecting to host <网关 A 地址>, port 5201
Reverse mode, remote host <网关 A 地址> is sending
[  5] local <手机内网地址> port 6231 connected to <网关 A 地址> port 5201
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.03  sec  23.6 MBytes  19.8 Mbits/sec   50            sender
[  5]   0.00-10.01  sec  23.1 MBytes  19.4 Mbits/sec                  receiver

iperf Done.

这里其实已经发现了奇怪的问题,测速竟然又是好的了,虽然没有跑满网关 A 的上行,但基本也够我回城看个 Grafana 监控了.

问题

经过这些测试,彻底想不通为啥手机上 Wireguard APP 下只有 0.1Mbps 的下行了,既然用分享的热点电脑能正常速率通信,那么手机的流量应该是没问题的.

Wireguard 的 APP 我也试了几个老版本的,发现问题并不能得到缓解,仍然速率非常的慢.另外我还试了下 iperf 直接对网关进行测试,发现不论是 TCP 还是 UDP,通信速率都是正常的.

我还试了一下在腾讯云买了一台带 IPv6,和已有服务器不同 VPC 的主机,试了一下 IPv6 直连网关 A 的速度,也是正常的.

写了也比较多了,希望能有大佬可以帮忙分析下问题所在.

2570 次点击
所在节点    宽带症候群
19 条回复
NealLason
119 天前
先 降低 MTU 到 512 字节试试
JerryYuan
119 天前
@NealLason 感谢回复，这边试了一下把 Wireguard 的 MTU 降低到 512 ，似乎没有什么变化：
![测速]( )
Ipsum
119 天前
跨网限速，电信甚至通网都限速。试试 ovpn 的 tcp 模式。
NealLason
119 天前
@JerryYuan 好吧，那和我的现象不一样。我是把互相通信的两个 peer 的 MTU 都配置成 512 ，吞吐就恢复正常了，1460 反而 QoS 严重。
JerryYuan
119 天前
@Ipsum 我跨网的那条链路测下来问题不大，只是我手机流量这条链路有问题，手机和网关 A 都是移动网，按理说不存在跨地区或者跨网的说。

我又补充测试了一个，挂上 wstunnel 转成 TCP 去回城网速确实能恢复，这样看确实是移动加强蜂窝网络的 UDP QoS 了？

另外我笔记本走热点回城速度却又不受影响应该怎么解释呢😂
JerryYuan
119 天前
@NealLason 诶？我只改了手机一侧，一会试下网关的 MTU 也改 512 试下
yinmin
119 天前
网关 A 的 wireguard 的 mtu 改成 1200 ，手机的 wireguard 的 mtu 也改成 1200 ，然后再试试，wireguard 奇奇怪怪的问题很多都是 mtu 的原因。
JerryYuan
119 天前
@yinmin @NealLason 感谢大佬们的回复,试了一下网关 A 的 MTU 改成 1200,速度就恢复了,这样看确实是 MTU 的问题.所以原理就是 wg 的 UDP 包太大,导致被移动给丢了?然后笔记本走热点恰巧 MTU 选了一个小的值,速度就正常?

稍后我再试下如果给笔记本指定 1400,看看能不能复现问题.
linzyjx
119 天前
第一直觉是跨网限速。不过确实碰到过好几回 mobile 网络接入的时候 MTU 设成 1400 左右连不上，1200 可以的问题
Naples
119 天前
Wireguard MTU: over ipv4, 1432; over ipv6, 1412.
xqzr
118 天前
@NealLason > 1460 反而 QoS 严重

IPv4 Endpoint 最多就 1440 ； IPv6 Endpoint 1420 （物理网卡 1500 情况下）

腾讯云的网络，需要减小 36 。所以，IPv4 Endpoint 1404
AlphaTauriHonda
118 天前
AmneziaWG ，实在不行只能 TCP 。
JerryYuan
118 天前
@linzyjx 我这比较尴尬，跨网跨省的反而没事，市内通信先挂了😂另外我用最后热点的方案试了下 1400 的，似乎没有复现手机的问题

@Naples 我这比较尴尬，peer 之间既有 ipv4 的也有 ipv6 的，感觉只能取小值设定一个了

@AlphaTauriHonda 我有 TCP 的备用方案了，用 wstunnel 套一下也能恢复，先用 UDP 的吧，毕竟省事，等实在不行了再考虑换协议吧
pxlxh
118 天前
搞这么复杂 一个环节挂了全挂
网盘解千愁

要达到网盘同样稳定性 需要投入五十倍以上
JerryYuan
118 天前
@pxlxh 目的不同罢了，网盘享受的是结果，NAS 享受的是折腾的过程以及解决技术问题时多巴胺的冲击。

btw ，不喜欢国产软件那个忽悠你用起来，等你离不开了再收割的尿性，利用这套东西，已经基本实现去国产化+90%以上开源方案了

另外从长远(数年)来看，相同体验下 NAS 和网盘投入的资金是差不多的
JensenQian
118 天前
wireguad 基于 udp
udp 喜欢 qos 运营商
跨网+udp ，这雪上加霜

建议还是用基于 tcp 的协议
allenby
117 天前
有一个 ws 实现的
swananan
117 天前
这个其实是 ip fragment 导致的，本质上要传输层自己搞个 mtu 探测就好了，但是一刀切 1200 似乎是个省事的办法
JerryYuan
117 天前
@JensenQian 有所耳闻，不过目前看还能用还够用就先用吧，等哪天真的不行了再换吧，搭这一套也花了不少时间

@swananan 那理论上应该是 MTU 加上包头长度在 IP 报允许的最大 payload 长度附近了，导致产生一大堆小包？我还试了 MTU 拉到离谱大，似乎也不会出现限速问题，大概是因为强制分包导致包长度能回到合理范围？

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1134033

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX