这是一个创建于 431 天前的主题，其中的信息可能已经有所发展或是发生改变。
网络拓扑结构
-
ROS 主路由: 192.168.21.1
- 负责 DHCP 和路由
- 默认的国内路由
- 从 Debian 广播过来的国外路由（已经排除节点 IP ）
-
Debian 旁路由: 192.16821.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 上去
- 通过 mosdns 负责国内外 DNS 分流
-
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 出去
遇到的问题
在实际使用过程中，国内网速正常，但国外网页打开非常慢。以下是已经进行的排查步骤：
-
Mac 上直接使用 fakeip 模式:
- 正常使用，排除节点速度问题。
-
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 -
局域网内设备使用分配的网关 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 做网关时分流网速也能正常，希望各位大神能帮忙看看哪里出了问题，感谢！
第 1 条附言 2024-08-06 12:32:21 +08:00
我找到原因了，是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 条附言 2024-08-09 09:56:46 +08:00
听劝，这条规则还是重要的，在 ros 和 debian 上 ipv4 都加了 masquerade 后恢复正常了，ipv6 的没加，暂时没有发现问题
 | 1 povsister 2024-08-05 22:20:48 +08:00  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 2024-08-6 10:37:14 +08:00 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 2024-08-06 10:42:13 +08:00 via iPhone 你的 debian 出口是 tun0 ，试试： iptables -t nat -A POSTROUTING -s 192.168.21.0/24 -o tun0 -j MASQUERADE |
| 5 yinmin 2024-08-06 11:18:53 +08:00 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 2024-08-06 11:19:58 +08:00 via iPhone 上面的 192.168.1.49 写错了，是 192.168.21.49 |
 | 7 EGOISTK21 OP @yinmin 好，我今天回家试试，昨晚上只在 debian 上试了 masquerade ，没有用 |
| 9 povsister 2024-08-06 13:33:48 +08:00 1 @EGOISTK21 这个不能算误判，你考虑下 packet path ，你会发现是合理的。ROS 的 conn-track 是 stateful 的，对于 TCP 来说双向的数据报文都被 track 到，tcp 进入 establish 状态后路由器才会正常转发报文。 非对称路由在有状态防火墙上吃瘪是常事，我倒是不建议你粗暴的把这个规则去掉。input 链上的规则还是很重要的。 |
| 10 EGOISTK21 OP @povsister 言之有理，直接放通只能暂缓。现在还有部分能力，如群晖的端口映射、surge 的 ponte 回家，都是有问题的，还得再优化摸索一下，我得补充一下知识再战 |
| 11 yinmin 2024-08-06 16:56:01 +08:00 @EGOISTK21 不对称路由是有问题的。你试试浏览器访问 sohu.com ，然后 ctrl+点击链接，快速开启几十个新窗口，看看会不会卡； https://weixin.qq.com 、https://house.focus.cn 会不会卡顿。 解决不对称路由，要么用#1 楼的方法: 旁路由做独立网段；要么用 MASQUERADE 做 IP 伪装。 |
 | 12 zealic 2024-08-07 01:17:48 +08:00 @povsister 这种情况如果是 ROS 在 Settings 里面关掉 Send Redirect 就可以了。 另外没搞懂为啥楼主要用 OSPF ，这个情况应该在 ROS 中导入一个 ipset ，然后 mangle 做分流就行，路由表太大也会影响性能的。 参见我做的 [autoros 脚本]( https://github.com/zealic/autorosvpn/blob/master/chnroutes.rsc) |
| 13 povsister 2024-08-07 11:28:44 +08:00 @zealic mangle 如果要干预路由决策，需要 mark routing ，会直接导致 fasttrack 失效。 实际性能会比路由表更低，路由表查询的代价比跑一遍 firewall 的 slowpath 要低太多了。 |
| 14 zealic 2024-08-07 12:05:41 +08:00 @povsister 本身楼主的场景跑的旁路由模式下，这个开销和最终路径远远大于 fasttrack 。 但是如果不做旁路由，RouterOS 性能足够高的情况下直接跑 WG/ZT 或者 RouterOS 内容器化跑其他软件，必然也是会有走 slowpath ，吃不到 fasttrack 。 我的配置里，只有 chnroutes 能吃到 fasttrack ，这个才是体感大头， 毕竟 fasttrack 加速上限和出去的距离物理硬延迟比起来也是九牛一毛。 |
| 15 povsister 2024-08-07 12:11:32 +08:00 @zealic wg/zt 本身是不适合魔法场景的，过墙能力太差，ros 容器限制又太多，OP 的场景也是旁路由单独跑。 另外，旁路由模式不代表无法 fasttrack 呀，在 L3 拓扑上旁路由就是正常的下一跳，不加 mangle 的情况下是可以正常 fasttrack 的，LAN to ROS ，旁路由 to ROS wan 都可以正常 fasttrack |
| 16 zealic 2024-08-07 13:03:05 +08:00 @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 2024-08-07 13:47:22 +08:00 @zealic 你描述的其实和 OP 用的没有本质区别，只不过你描述的 PolicyMode 可以省一个旁路的设备。 我不推荐 ROS 直接挂 WG 原因 一是，过墙能力差，很容易被针对。而且 ROS 本身的魔法能力，相比*ray/clash 等一堆 core 还是差了太多。 二是，这部分魔法流量走 PolicyRouting+WG 本质也是进用户态处理，会直接拉高 ROS 的负载。 走旁路的话，相当于魔法策略全部 offload 给旁路由，这样无论是带宽还是功能都是可以按需 scale 的。而不用考虑 ROS 本身的硬件负载能力。 |
| 18 EGOISTK21 OP |
 | 20 mmc 224 天前 旁路由不需要 NAT ，主路由做 NAT 到旁路由就行了 （/ip firewall nat add action=masquerade chain=srcnat comment="bypass snat" out-interface=LANBridge ），只要不用旁路由当旁路网关就不需要开 NAT ，主路由做了 NAT 后，旁路由就会认为是主路由访问自己，拿到数据后就直接给到主路由了。 举个例子，客户端访问 curl 1.1.1.1 。ros 判断是国外路由交给旁路由处理，对于旁路由来说是主路由访问 1.1.1.1 ，旁路由回代理这个请求（不是路由转发），不管走没走代理对于主路由来说都是旁路由在访问 1.1.1.1 或者节点，旁路由拿到数据后再转发主路由，主路由才给回客户端。这个过程根本不需要旁路由的 NAT 功能。除非说你的旁路由防火墙排除了 1.1.1.1 这个 ip 不走 tun0 而是直接转发到主路由（比如某些代理软件的绕过中国流量功能，又恰好这个 ip 在 ros 路由表中） |
Select Language