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

137 天前
 EGOISTK21

网络拓扑结构

网络配置

遇到的问题

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

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

1797 次点击
所在节点    宽带症候群
19 条回复
povsister
137 天前
旁路由模式推荐将旁路由和网关放在一个独立的网段内,否则下行流量(即由网关返回的响应)会直接由旁路由回复给 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
137 天前
@povsister 多谢解惑,我在别的帖子里有看到过这个非对称路由,我去调整一下试试
yinmin
136 天前
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
136 天前
你的 debian 出口是 tun0 ,试试:

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

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

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

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

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

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

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

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

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

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

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

走旁路的话,相当于魔法策略全部 offload 给旁路由,这样无论是带宽还是功能都是可以按需 scale 的。而不用考虑 ROS 本身的硬件负载能力。
EGOISTK21
134 天前
@povsister @zealic 我思考了一下,是这样二选一对吧,1 、Debian 搞一个独立网段 2 、Debian 回包的流量在 ROS 做 masquerade
EGOISTK21
134 天前
@yinmin 解决了,在 ros 和 debian 上都加 masquerade

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

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

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

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

© 2021 V2EX