V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
JerryYuan
V2EX  ›  宽带症候群

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

  •  
  •   JerryYuan · 22 天前 · 1962 次点击

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

    背景

    我在城市 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 的速度,也是正常的.

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

    第 1 条附言  ·  22 天前
    最新结论: 是 MTU 的问题,隧道双方 Peer 都改成 1200 就可以恢复速率了
    19 条回复    2025-05-26 14:17:22 +08:00
    NealLason
        1
    NealLason  
       22 天前
    先 降低 MTU 到 512 字节试试
    JerryYuan
        2
    JerryYuan  
    OP
       22 天前
    @NealLason 感谢回复,这边试了一下把 Wireguard 的 MTU 降低到 512 ,似乎没有什么变化:
    ![测速]( )
    Ipsum
        3
    Ipsum  
       22 天前
    跨网限速,电信甚至通网都限速。试试 ovpn 的 tcp 模式。
    NealLason
        4
    NealLason  
       22 天前
    @JerryYuan 好吧,那和我的现象不一样。我是把互相通信的两个 peer 的 MTU 都配置成 512 ,吞吐就恢复正常了,1460 反而 QoS 严重。
    JerryYuan
        5
    JerryYuan  
    OP
       22 天前 via Android
    @Ipsum 我跨网的那条链路测下来问题不大,只是我手机流量这条链路有问题,手机和网关 A 都是移动网,按理说不存在跨地区或者跨网的说。

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

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

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

    IPv4 Endpoint 最多就 1440 ; IPv6 Endpoint 1420 (物理网卡 1500 情况下)

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

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

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

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

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

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

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

    @swananan 那理论上应该是 MTU 加上包头长度在 IP 报允许的最大 payload 长度附近了,导致产生一大堆小包?我还试了 MTU 拉到离谱大,似乎也不会出现限速问题,大概是因为强制分包导致包长度能回到合理范围?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3423 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 04:32 · PVG 12:32 · LAX 21:32 · JFK 00:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.