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

[EGOISTK21]

网络拓扑结构

• 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 做网关时分流网速也能正常，希望各位大神能帮忙看看哪里出了问题，感谢！

我找到原因了，是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都没有关系，感谢大家的回复

听劝，这条规则还是重要的，在 ros 和 debian 上 ipv4 都加了 masquerade 后恢复正常了，ipv6 的没加，暂时没有发现问题

[povsister]

旁路由模式推荐将旁路由和网关放在一个独立的网段内，否则下行流量（即由网关返回的响应）会直接由旁路由回复给 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]

@povsister 多谢解惑，我在别的帖子里有看到过这个非对称路由，我去调整一下试试

[yinmin]

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]

你的 debian 出口是 tun0 ，试试：

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

[yinmin]

我仔细分析了一下，你的问题是非对称路由造成的，也就是 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]

上面的 192.168.1.49 写错了，是 192.168.21.49

[EGOISTK21]

@yinmin 好，我今天回家试试，昨晚上只在 debian 上试了 masquerade ，没有用

[EGOISTK21]

@povsister @yinmin 已经修好了，Append 在上面了，感谢二位

[povsister]

@EGOISTK21 这个不能算误判，你考虑下 packet path ，你会发现是合理的。ROS 的 conn-track 是 stateful 的，对于 TCP 来说双向的数据报文都被 track 到，tcp 进入 establish 状态后路由器才会正常转发报文。
非对称路由在有状态防火墙上吃瘪是常事，我倒是不建议你粗暴的把这个规则去掉。input 链上的规则还是很重要的。

[EGOISTK21]

@povsister 言之有理，直接放通只能暂缓。现在还有部分能力，如群晖的端口映射、surge 的 ponte 回家，都是有问题的，还得再优化摸索一下，我得补充一下知识再战

[yinmin]

@EGOISTK21 不对称路由是有问题的。你试试浏览器访问 sohu.com ，然后 ctrl+点击链接，快速开启几十个新窗口，看看会不会卡； https://weixin.qq.com 、https://house.focus.cn 会不会卡顿。

解决不对称路由，要么用#1 楼的方法: 旁路由做独立网段；要么用 MASQUERADE 做 IP 伪装。

[zealic]

@povsister 这种情况如果是 ROS 在 Settings 里面关掉 Send Redirect 就可以了。

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

参见我做的 [autoros 脚本]( https://github.com/zealic/autorosvpn/blob/master/chnroutes.rsc)

[povsister]

@zealic
mangle 如果要干预路由决策，需要 mark routing ，会直接导致 fasttrack 失效。
实际性能会比路由表更低，路由表查询的代价比跑一遍 firewall 的 slowpath 要低太多了。

[zealic]

@povsister 本身楼主的场景跑的旁路由模式下，这个开销和最终路径远远大于 fasttrack 。
但是如果不做旁路由，RouterOS 性能足够高的情况下直接跑 WG/ZT 或者 RouterOS 内容器化跑其他软件，必然也是会有走 slowpath ，吃不到 fasttrack 。

我的配置里，只有 chnroutes 能吃到 fasttrack ，这个才是体感大头，
毕竟 fasttrack 加速上限和出去的距离物理硬延迟比起来也是九牛一毛。

[povsister]

@zealic
wg/zt 本身是不适合魔法场景的，过墙能力太差，ros 容器限制又太多，OP 的场景也是旁路由单独跑。

另外，旁路由模式不代表无法 fasttrack 呀，在 L3 拓扑上旁路由就是正常的下一跳，不加 mangle 的情况下是可以正常 fasttrack 的，LAN to ROS ，旁路由 to ROS wan 都可以正常 fasttrack

[zealic]

@povsister 有没有一种可能，法术是可以叠加嵌套施法的？

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

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

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

WG 就目前看来是最适合做嵌套的协议，至于每个人的的法术套路都不一样，深究无用。

[povsister]

@zealic
你描述的其实和 OP 用的没有本质区别，只不过你描述的 PolicyMode 可以省一个旁路的设备。

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

走旁路的话，相当于魔法策略全部 offload 给旁路由，这样无论是带宽还是功能都是可以按需 scale 的。而不用考虑 ROS 本身的硬件负载能力。

[EGOISTK21]

@povsister @zealic 我思考了一下，是这样二选一对吧，1 、Debian 搞一个独立网段 2 、Debian 回包的流量在 ROS 做 masquerade

[EGOISTK21]

@yinmin 解决了，在 ros 和 debian 上都加 masquerade