ROS 主路由: 192.168.21.1
Debian 旁路由: 192.168.21.49
Mac: 192.168.21.2
在实际使用过程中,国内网速正常,但国外网页打开非常慢。以下是已经进行的排查步骤:
Mac 上直接使用 fakeip 模式:
Debian 上直接使用 curl:
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
局域网内设备使用分配的网关 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
局域网内设备指定网关为 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都没有关系,感谢大家的回复
1
povsister 113 天前 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 |
3
yinmin 113 天前 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 ) |
4
yinmin 113 天前 via iPhone
你的 debian 出口是 tun0 ,试试:
iptables -t nat -A POSTROUTING -s 192.168.21.0/24 -o tun0 -j MASQUERADE |
5
yinmin 113 天前 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 应该不需要 |
6
yinmin 113 天前 via iPhone
上面的 192.168.1.49 写错了,是 192.168.21.49
|
9
povsister 113 天前 1
@EGOISTK21 这个不能算误判,你考虑下 packet path ,你会发现是合理的。ROS 的 conn-track 是 stateful 的,对于 TCP 来说双向的数据报文都被 track 到,tcp 进入 establish 状态后路由器才会正常转发报文。
非对称路由在有状态防火墙上吃瘪是常事,我倒是不建议你粗暴的把这个规则去掉。input 链上的规则还是很重要的。 |
10
EGOISTK21 OP @povsister 言之有理,直接放通只能暂缓。现在还有部分能力,如群晖的端口映射、surge 的 ponte 回家,都是有问题的,还得再优化摸索一下,我得补充一下知识再战
|
11
yinmin 113 天前
@EGOISTK21 不对称路由是有问题的。你试试浏览器访问 sohu.com ,然后 ctrl+点击链接,快速开启几十个新窗口,看看会不会卡; https://weixin.qq.com 、https://house.focus.cn 会不会卡顿。
解决不对称路由,要么用#1 楼的方法: 旁路由做独立网段;要么用 MASQUERADE 做 IP 伪装。 |
12
zealic 112 天前
@povsister 这种情况如果是 ROS 在 Settings 里面关掉 Send Redirect 就可以了。
另外没搞懂为啥楼主要用 OSPF ,这个情况应该在 ROS 中导入一个 ipset ,然后 mangle 做分流就行,路由表太大也会影响性能的。 参见我做的 [autoros 脚本]( https://github.com/zealic/autorosvpn/blob/master/chnroutes.rsc) |
13
povsister 112 天前
@zealic
mangle 如果要干预路由决策,需要 mark routing ,会直接导致 fasttrack 失效。 实际性能会比路由表更低,路由表查询的代价比跑一遍 firewall 的 slowpath 要低太多了。 |
14
zealic 112 天前
@povsister 本身楼主的场景跑的旁路由模式下,这个开销和最终路径远远大于 fasttrack 。
但是如果不做旁路由,RouterOS 性能足够高的情况下直接跑 WG/ZT 或者 RouterOS 内容器化跑其他软件,必然也是会有走 slowpath ,吃不到 fasttrack 。 我的配置里,只有 chnroutes 能吃到 fasttrack ,这个才是体感大头, 毕竟 fasttrack 加速上限和出去的距离物理硬延迟比起来也是九牛一毛。 |
15
povsister 112 天前
@zealic
wg/zt 本身是不适合魔法场景的,过墙能力太差,ros 容器限制又太多,OP 的场景也是旁路由单独跑。 另外,旁路由模式不代表无法 fasttrack 呀,在 L3 拓扑上旁路由就是正常的下一跳,不加 mangle 的情况下是可以正常 fasttrack 的,LAN to ROS ,旁路由 to ROS wan 都可以正常 fasttrack |
16
zealic 112 天前
@povsister 有没有一种可能,法术是可以叠加嵌套施法的?
另外你说的场景我描述一下链路: SideMode: CLIENT->MainRouter(fasttrack)->SideRouter(linux mangle->magic)->MainRouter(fasttrack->WAN) PolicyMode: CLIENT->MainRouter(mangle->WG(magic)->fasttrack->WAN) 旁路模式只是把策略路由这一部分交给了旁路由的 linux mangle ,甚至需要直接在用户空间下处理。 WG 就目前看来是最适合做嵌套的协议,至于每个人的的法术套路都不一样,深究无用。 |
17
povsister 112 天前
@zealic
你描述的其实和 OP 用的没有本质区别,只不过你描述的 PolicyMode 可以省一个旁路的设备。 我不推荐 ROS 直接挂 WG 原因 一是,过墙能力差,很容易被针对。而且 ROS 本身的魔法能力,相比*ray/clash 等一堆 core 还是差了太多。 二是,这部分魔法流量走 PolicyRouting+WG 本质也是进用户态处理,会直接拉高 ROS 的负载。 走旁路的话,相当于魔法策略全部 offload 给旁路由,这样无论是带宽还是功能都是可以按需 scale 的。而不用考虑 ROS 本身的硬件负载能力。 |
18
EGOISTK21 OP |