软路由的最佳实践

对多数用户来说，软路由最佳实践应该是透明代理网关，俗称旁路由

最近在折腾软路由，谈下对软路由看法，软路由当旁路由是由其缺点决定的，缺点包括系统不稳定，网络层能力弱于硬路由。以常见的 openWrt 为例，相比硬路由，出现挂掉的概率更高，硬路由设计时主要针对网络层，在如 NAT 、小包转发上天生就比软路由优秀，软路由则是针对应用层设计的系统，应用层要求更高的通用计算力处理流量，典型应用是代理服务，软路由在这个层面就表现得非常优秀。从网络分层角度看，硬路由和软路由不是同一个层次的东西

软路由当旁路由使用能很好利用软路由的优点和硬路由的优点，非侵入式接入不影响原有的网络架构

吐槽下旁路由这个名字太形象了🤣，很中文，放在主路由旁边的路由

经常看到有人总是想跑满带宽或升级带宽，不明白背后的需求是什么，要求持续高带宽的场景非常少，带宽到达一定速度后边际收益递减，与其追求带宽上的快，不如优化网络延迟，买个延迟更低的机场更香

neroxps

2023-06-30 10:00:38 +08:00

@oovveeaarr #57 fake-ip 仅仅只解析给爬墙的域名，既然爬墙的域名必须走代理，那么爬墙的流量的网络的完整性还有必要吗？对于国内域名，获得的 IP 地址是真实 IP ，在国内流量里，是完整的网络。icmp 等协议都是一样的跑法。

> ping www.bilibili.com
PING www.bilibili.com(240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30)) 56 data bytes
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=1 ttl=56 time=8.10 ms
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=2 ttl=56 time=9.11 ms
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=3 ttl=56 time=8.89 ms
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=4 ttl=56 time=9.95 ms
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=5 ttl=56 time=9.65 ms
^C
--- www.bilibili.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 8.102/9.138/9.949/0.640 ms
> ping www.bilibili.com -4
PING (59.36.228.17) 56(84) bytes of data.
64 bytes from 17.228.36.59.broad.jm.gd.dynamic.163data.com.cn (59.36.228.17): icmp_seq=1 ttl=56 time=4.86 ms
64 bytes from 17.228.36.59.broad.jm.gd.dynamic.163data.com.cn (59.36.228.17): icmp_seq=2 ttl=56 time=5.31 ms
64 bytes from 17.228.36.59.broad.jm.gd.dynamic.163data.com.cn (59.36.228.17): icmp_seq=3 ttl=56 time=6.23 ms
64 bytes from 17.228.36.59.broad.jm.gd.dynamic.163data.com.cn (59.36.228.17): icmp_seq=4 ttl=56 time=4.36 ms
^C
--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 4.359/5.189/6.231/0.689 ms
> ping www.google.com
PING www.google.com (198.18.0.3) 56(84) bytes of data.
64 bytes from 198.18.0.3 (198.18.0.3): icmp_seq=1 ttl=60 time=1.33 ms
64 bytes from 198.18.0.3 (198.18.0.3): icmp_seq=2 ttl=60 time=1.06 ms
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 1.056/1.193/1.330/0.137 ms

> traceroute -n www.bilibili.com
traceroute to www.bilibili.com (59.36.228.17), 30 hops max, 60 byte packets
1 10.89.0.1 1.180 ms 1.107 ms 1.103 ms
2 *.*.*.* 2.914 ms 3.292 ms 3.240 ms
3 14.148.6.89 2.624 ms 14.148.6.81 2.461 ms 14.148.6.89 2.555 ms
4 14.148.2.149 3.421 ms * *
5 * 183.61.221.138 9.633 ms 183.59.12.2 5.502 ms
6 * * *
7 59.39.4.62 3.892 ms 183.57.144.2 3.880 ms *
8 * * *
9 59.36.228.17 4.533 ms 4.185 ms 6.581 ms
>
> traceroute -n6 www.bilibili.com
traceroute to www.bilibili.com (240e:97d:2000:c0e::32), 30 hops max, 80 byte packets
1 240e:*:*:*::1 0.323 ms 0.302 ms 0.273 ms
2 240e:1e:8000::56 1.701 ms 1.837 ms 1.735 ms
3 240e:1e:851d:2::1 1.501 ms 240e:1e:851d:1::1 1.462 ms 240e:1e:851d:4::1 1.471 ms
4 240e:1e:8401:12::1 2.844 ms 2.833 ms 240e:1e:8400:10::1 4.915 ms
5 240e:1f:d000:ff00::3 5.146 ms 6.149 ms 240e:1f:d000:46::3 6.292 ms
6 240e:1f:d000:83::3 4.908 ms 5.018 ms 240e:1f:d000:85::3 7.331 ms
7 240e:97d:2000:900::69 4.145 ms 240e:1f:d809::e:3 6.757 ms 240e:1f:d809::c:3 8.398 ms
8 240e:97d:2000:900::65 3.519 ms 240e:97d:2000:900::69 6.590 ms 240e:97d:2000:c0d::3 5.176 ms
9 240e:97d:2000:c0d::1 7.611 ms 240e:97d:2000:c0d::3 5.074 ms 240e:97d:2000:c0e::32 4.462 ms
> traceroute -n www.google.com
traceroute to www.google.com (198.18.0.3), 30 hops max, 60 byte packets
1 10.89.0.1 0.418 ms 0.317 ms 0.306 ms
2 172.16.222.2 0.914 ms 0.935 ms 0.885 ms^C

neroxps

2023-06-30 10:02:30 +08:00

@sun82kg 您的方案的确更简单，还做了静态 DNS 分流。已收藏。

Cursor1st

2023-06-30 10:46:55 +08:00

@sun82kg 已收藏学习。
目前我的方案是 ROS+OP ，ROS 的 dns 指向 op ，op 的 openclash 判断分流与否。国内的转 op 内部 adguard home 解析最快 ip ，并返回真实 ip 。国外的返回 fake-ip 。当 ip 返回给客户端时，在主路由 ROS 做判断，fake-ip 路由到 op ，真实 ip 直接出去。

archxm

2023-06-30 10:52:06 +08:00

家里人经常网购的话，还是以稳定靠谱为第一考虑点

cocomiko

2023-06-30 10:59:02 +08:00

@neroxps 我这里没搞 dns 分流，我是直接在 ros 上设置 53 端口转发，把需要翻墙的机子加入名单里，只有名单里的机子才会转发到 op 的 dns 服务器上，这样我可以在 ros 上随意指定一台 ip 是否翻墙，而且是实时的，但是很少看到别人使用这种方式，不知道这种方式有什么不好，我自己用了一年多了，觉得挺方便的

shyrock

2023-06-30 11:03:22 +08:00

@Donahue #39 ophub?没找到呢

msvcr110

2023-06-30 11:12:19 +08:00

主路由从换成华硕换成 TP Link 之后，旁路由就出问题了，还要另外加 iptables 规则。但是 xbox 还是 NAT 出问题，打算弃用旁路由了，花点小钱买个 x86 拨号算了

zmcity

2023-06-30 11:19:23 +08:00

旁路由要配合 fakeip+静态路由做。
这样可以保证去回程一致。

neroxps

2023-06-30 11:37:52 +08:00

@shijingshijing 其实软路由主要是小包并发和多线程问题。但是这些问题一般不会出现在家庭网络里。

neroxps

2023-06-30 11:45:20 +08:00

@cocomiko 这样的做法就是一刀切，爬墙的机器如果连国内的流量依然是要跑到 openwrt 。例如我某个机器上跑了 docker 里面有 qbittorrent 和 emby 。那么 emby 搜刮的时候需要爬墙，但 qbittorrent 流量跑到 openwrt 会损失性能，这样就很麻烦，需要对 qbittorrent 做 macvlan 分配一个独立的 IP 给它。多了一层 macvlan 对设备性能也是一种损耗，维护复杂度也增加了，当然这种损耗和复杂度不值一提，但这是因为网络拓扑的问题而导致的。那么为什么不直接在拓扑上解决这种需求？如果我维护的还有其他机器，那么维护难度就增加了。最直接的方案还是基于目的地分流，这个流量是要跑到梯子的，就跑到梯子，是直接出去的，就直接跑出去。

Donahue

2023-06-30 11:46:49 +08:00

@shyrock https://github.com/xiaomeng9597/OpenWrt/releases 这有个插件挺全的，可以加群 736056829 玩

Jirajine

2023-06-30 11:49:44 +08:00

@thereone dhcp 走主路由就无法处理 ipv6 ，因为 RA 只能广播自己作为默认网关。不处理 ipv6 要么关掉 ipv6 要么出现泄漏，因为 ipv6 会直连。
内网多了一跳会导致多种问题，比如 nat 打洞、upnp 端口转发的去回程流量可能会走不同的路径，这部分流量可能会也可能不会被代理。去回程路径不同也会导致如你在旁路由上设置防火墙规则，上行生效下行就失效了。
以及“旁路由”就是一台普通服务器，你要是这里也用 openwrt 那还不如直接 openwrt 主路由 all in one 。
“单点故障”阻断链路是应有的行为，代理挂了就应该代理流量断网，而非所有流量静默的直接泄漏出去。而透明网桥对三层网络是透明的，你想移除他只需要把网线一拔，直接插到主路由上，网络自然恢复默认状态。

KKLeon

2023-06-30 11:51:04 +08:00

@8355 说旁路由体验垃圾的还是自己没弄明白，我的 n1 旁路由几年了，稳定的一批。比红米 ax6 刷 openwrt 还稳

neroxps

2023-06-30 11:57:37 +08:00

>> 这些用户搞更复杂的网络，他们收益其实很低，除了能自娱自乐，回帖秀下优越感之外，对网络改善效果非常少。

这样说，一切以需求出发。相信弄更复杂的网络用户并非为了自娱自乐，每个人也有自己需要解决的痛点。
只是楼主在谈论最佳实践，站在网络的角度，每个人有不同的理解。

对于局域网里跑 PCDN 和 PT 的用户一台逻辑设备混合各种业务，基于源 IP 地址的分流（手动修改网关和 DNS ）在我看来，并非最佳实践。

网络的事，交给网络设备去做。docker 划分 macvlan 分配多个 IP ，这种做法的确可以解决需求，但我看来，并非最佳实践。