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

mosdns 域名分流+OSPF IP 分流遇到网速问题求助

  •  
  •   EGOISTK21 · 107 天前 · 1694 次点击
    这是一个创建于 107 天前的主题,其中的信息可能已经有所发展或是发生改变。

    网络拓扑结构

    • ROS 主路由: 192.168.21.1

      • 负责 DHCP 和路由
      • 默认的国内路由
      • 从 Debian 广播过来的国外路由(已经排除节点 IP )
    • Debian 旁路由: 192.168.21.49

      • 通过 mosdns 负责国内外 DNS 分流
        • mosdns 监听端口: 5335
        • adguardhome 监听端口: 53
      • bird2 广播国外 IPv4 和 IPv6 路由,下一跳为 tun0
      • tun0 上启用 tun2socks ,指向 Mac 上的 socks5 代理 (192.168.21.2:6153)
      • 现在链路很长,等错误排查后会把 Debian 的能力分摊到 ROS 容器化 mosdns 和 Mac 的 tun 上去
    • Mac: 192.168.21.2

      • xray 起了一个 socks5 代理 (192.168.21.2:6153)

    网络配置

    • ROS 的 DHCP:
      • 下发网关: 192.168.21.1
      • DNS: 192.168.21.49
    • 国内网址访问:
      • mosdns 分流到阿里 DNS 解析出国内 IP
      • 通过 pppoe 网关直接出去
    • 国外网址访问:
      • mosdns 分流到谷歌 DNS 解析出国外 IP
      • 命中 OSPF 动态路由
      • 经过 Debian 的 eth0 和 tun0 ,再到 Mac 的 en0
      • 通过 socks5 代理转成访问节点 IP 的流量 ,节点 IP 的路由从网关的 pppoe 出去

    遇到的问题

    在实际使用过程中,国内网速正常,但国外网页打开非常慢。以下是已经进行的排查步骤:

    1. Mac 上直接使用 fakeip 模式:

      • 正常使用,排除节点速度问题。
    2. Debian 上直接使用 curl:

      • 速度正常,排除 socks2tun 的性能问题。
      curl -o /dev/null -s -w "DNS Lookup Time: %{time_namelookup}\nConnect Time: %{time_connect}\nPre-transfer Time: %{time_pretransfer}\nStart Transfer Time: %{time_starttransfer}\nTotal Time: %{time_total}\n" https://www.google.com
      DNS Lookup Time: 0.003929
      Connect Time: 0.004312
      Pre-transfer Time: 0.595990
      Start Transfer Time: 0.896633
      Total Time: 0.955273
      
    3. 局域网内设备使用分配的网关 192.168.21.1:

      • 国外网页速度慢。
      curl -o /dev/null -s -w "DNS Lookup Time: %{time_namelookup}\nConnect Time: %{time_connect}\nPre-transfer Time: %{time_pretransfer}\nStart Transfer Time: %{time_starttransfer}\nTotal Time: %{time_total}\n" https://www.google.com
      DNS Lookup Time: 0.007470
      Connect Time: 0.008478
      Pre-transfer Time: 5.785127
      Start Transfer Time: 6.088621
      Total Time: 6.281218
      
    4. 局域网内设备指定网关为 192.168.21.49:

      • 国外网页速度恢复正常。
      curl -o /dev/null -s -w "DNS Lookup Time: %{time_namelookup}\nConnect Time: %{time_connect}\nPre-transfer Time: %{time_pretransfer}\nStart Transfer Time: %{time_starttransfer}\nTotal Time: %{time_total}\n" https://www.google.com
      DNS Lookup Time: 0.003851
      Connect Time: 0.004212
      Pre-transfer Time: 0.490562
      Start Transfer Time: 0.670804
      Total Time: 0.734074
      

    我想做到在使用 ROS 做网关时分流网速也能正常,希望各位大神能帮忙看看哪里出了问题,感谢!

    第 1 条附言  ·  107 天前

    我找到原因了,是ROS防火墙的filter规则里有一条

    5    ;;; defconf: drop invalid
          chain=input action=drop connection-state=invalid log=no log-prefix=""
    

    导致流量被误判为无效连接而被丢弃,从而引起速度变慢的问题,我把它禁用掉就恢复了,还有IPv6里一条一样的也禁掉,跟mtu、net.ipv4.conf.all.rp_filter、MASQUERADE都没有关系,感谢大家的回复

    第 2 条附言  ·  104 天前
    听劝,这条规则还是重要的,在 ros 和 debian 上 ipv4 都加了 masquerade 后恢复正常了,ipv6 的没加,暂时没有发现问题
    19 条回复    2024-08-08 21:33:31 +08:00
    povsister
        1
    povsister  
       107 天前   ❤️ 2
    旁路由模式推荐将旁路由和网关放在一个独立的网段内,否则下行流量(即由网关返回的响应)会直接由旁路由回复给 LAN 内的设备,造成非对称路由。
    这在某些情况下可能会造成意想不到的问题。你这个 case 看起来就像是这样。

    拓扑配置,可借鉴我自用的类似方案 https://github.com/povsister/v2ray-core

    给你参考下我这正确配置的情况

    curl -o /dev/null -s -w "DNS Lookup Time: %{time_namelookup}\nConnect Time: %{time_connect}\nPre-transfer Time: %{time_pretransfer}\nStart Transfer Time: %{time_starttransfer}\nTotal Time: %{time_total}\n" https://google.com

    * Host google.com:443 was resolved.
    * IPv6: (none)
    * IPv4: 172.217.174.110
    * Trying 172.217.174.110:443...
    * Connected to google.com (172.217.174.110) port 443

    DNS Lookup Time: 0.004620
    Connect Time: 0.006571
    Pre-transfer Time: 0.328742
    Start Transfer Time: 0.416287
    Total Time: 0.428822
    EGOISTK21
        2
    EGOISTK21  
    OP
       107 天前
    @povsister 多谢解惑,我在别的帖子里有看到过这个非对称路由,我去调整一下试试
    yinmin
        3
    yinmin  
       107 天前 via iPhone
    debian 开启 MASQUERADE 试试

    iptables -t nat -A POSTROUTING -s 192.168.21.0/24 -o eth0 -j MASQUERADE

    eth0 是 debian 192.168.21.49 所在的网卡编号(有些 debian 系统是 end0 )
    yinmin
        4
    yinmin  
       107 天前 via iPhone
    你的 debian 出口是 tun0 ,试试:

    iptables -t nat -A POSTROUTING -s 192.168.21.0/24 -o tun0 -j MASQUERADE
    yinmin
        5
    yinmin  
       107 天前 via iPhone
    我仔细分析了一下,你的问题是非对称路由造成的,也就是 pc - 192.168.21.1 - 192.168.1.49 ,但是返回数据是 192.168.1.49 直接返回给 pc ,没有回流 192.168.21.1

    同样,如果你使用 192.168.1.49 网关,访问国内网站也会遇到非对称路由的困扰(你试试浏览器访问 sohu.com ,然后 ctrl+点击链接,快速开启 10 多个新窗口,看看会不会卡)

    你需要在主路由和旁路由都开启 MASQUERADE:

    iptables -t nat -A POSTROUTING -s 192.168.21.0/24 -o eth0 -j MASQUERADE

    debian 的-o tun0 应该不需要
    yinmin
        6
    yinmin  
       107 天前 via iPhone
    上面的 192.168.1.49 写错了,是 192.168.21.49
    EGOISTK21
        7
    EGOISTK21  
    OP
       107 天前 via iPhone
    @yinmin 好,我今天回家试试,昨晚上只在 debian 上试了 masquerade ,没有用
    EGOISTK21
        8
    EGOISTK21  
    OP
       107 天前
    @povsister @yinmin 已经修好了,Append 在上面了,感谢二位
    povsister
        9
    povsister  
       107 天前   ❤️ 1
    @EGOISTK21 这个不能算误判,你考虑下 packet path ,你会发现是合理的。ROS 的 conn-track 是 stateful 的,对于 TCP 来说双向的数据报文都被 track 到,tcp 进入 establish 状态后路由器才会正常转发报文。
    非对称路由在有状态防火墙上吃瘪是常事,我倒是不建议你粗暴的把这个规则去掉。input 链上的规则还是很重要的。
    EGOISTK21
        10
    EGOISTK21  
    OP
       107 天前 via iPhone
    @povsister 言之有理,直接放通只能暂缓。现在还有部分能力,如群晖的端口映射、surge 的 ponte 回家,都是有问题的,还得再优化摸索一下,我得补充一下知识再战
    yinmin
        11
    yinmin  
       107 天前
    @EGOISTK21 不对称路由是有问题的。你试试浏览器访问 sohu.com ,然后 ctrl+点击链接,快速开启几十个新窗口,看看会不会卡; https://weixin.qq.comhttps://house.focus.cn 会不会卡顿。

    解决不对称路由,要么用#1 楼的方法: 旁路由做独立网段;要么用 MASQUERADE 做 IP 伪装。
    zealic
        12
    zealic  
       106 天前
    @povsister 这种情况如果是 ROS 在 Settings 里面关掉 Send Redirect 就可以了。

    另外没搞懂为啥楼主要用 OSPF ,这个情况应该在 ROS 中导入一个 ipset ,然后 mangle 做分流就行,路由表太大也会影响性能的。

    参见我做的 [autoros 脚本]( https://github.com/zealic/autorosvpn/blob/master/chnroutes.rsc)
    povsister
        13
    povsister  
       106 天前
    @zealic
    mangle 如果要干预路由决策,需要 mark routing ,会直接导致 fasttrack 失效。
    实际性能会比路由表更低,路由表查询的代价比跑一遍 firewall 的 slowpath 要低太多了。
    zealic
        14
    zealic  
       106 天前
    @povsister 本身楼主的场景跑的旁路由模式下,这个开销和最终路径远远大于 fasttrack 。
    但是如果不做旁路由,RouterOS 性能足够高的情况下直接跑 WG/ZT 或者 RouterOS 内容器化跑其他软件,必然也是会有走 slowpath ,吃不到 fasttrack 。

    我的配置里,只有 chnroutes 能吃到 fasttrack ,这个才是体感大头,
    毕竟 fasttrack 加速上限和出去的距离物理硬延迟比起来也是九牛一毛。
    povsister
        15
    povsister  
       106 天前
    @zealic
    wg/zt 本身是不适合魔法场景的,过墙能力太差,ros 容器限制又太多,OP 的场景也是旁路由单独跑。

    另外,旁路由模式不代表无法 fasttrack 呀,在 L3 拓扑上旁路由就是正常的下一跳,不加 mangle 的情况下是可以正常 fasttrack 的,LAN to ROS ,旁路由 to ROS wan 都可以正常 fasttrack
    zealic
        16
    zealic  
       106 天前
    @povsister 有没有一种可能,法术是可以叠加嵌套施法的?

    另外你说的场景我描述一下链路:
    SideMode:
    CLIENT->MainRouter(fasttrack)->SideRouter(linux mangle->magic)->MainRouter(fasttrack->WAN)

    PolicyMode:
    CLIENT->MainRouter(mangle->WG(magic)->fasttrack->WAN)

    旁路模式只是把策略路由这一部分交给了旁路由的 linux mangle ,甚至需要直接在用户空间下处理。

    WG 就目前看来是最适合做嵌套的协议,至于每个人的的法术套路都不一样,深究无用。
    povsister
        17
    povsister  
       106 天前
    @zealic
    你描述的其实和 OP 用的没有本质区别,只不过你描述的 PolicyMode 可以省一个旁路的设备。

    我不推荐 ROS 直接挂 WG 原因
    一是,过墙能力差,很容易被针对。而且 ROS 本身的魔法能力,相比*ray/clash 等一堆 core 还是差了太多。
    二是,这部分魔法流量走 PolicyRouting+WG 本质也是进用户态处理,会直接拉高 ROS 的负载。

    走旁路的话,相当于魔法策略全部 offload 给旁路由,这样无论是带宽还是功能都是可以按需 scale 的。而不用考虑 ROS 本身的硬件负载能力。
    EGOISTK21
        18
    EGOISTK21  
    OP
       105 天前
    @povsister @zealic 我思考了一下,是这样二选一对吧,1 、Debian 搞一个独立网段 2 、Debian 回包的流量在 ROS 做 masquerade
    EGOISTK21
        19
    EGOISTK21  
    OP
       104 天前
    @yinmin 解决了,在 ros 和 debian 上都加 masquerade
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3069 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 12:51 · PVG 20:51 · LAX 04:51 · JFK 07:51
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.