对多数用户来说,软路由最佳实践应该是透明代理网关,俗称旁路由
最近在折腾软路由,谈下对软路由看法,软路由当旁路由是由其缺点决定的,缺点包括系统不稳定,网络层能力弱于硬路由。以常见的 openWrt 为例,相比硬路由,出现挂掉的概率更高,硬路由设计时主要针对网络层,在如 NAT 、小包转发上天生就比软路由优秀,软路由则是针对应用层设计的系统,应用层要求更高的通用计算力处理流量,典型应用是代理服务,软路由在这个层面就表现得非常优秀。从网络分层角度看,硬路由和软路由不是同一个层次的东西
软路由当旁路由使用能很好利用软路由的优点和硬路由的优点,非侵入式接入不影响原有的网络架构
吐槽下旁路由这个名字太形象了🤣,很中文,放在主路由旁边的路由
经常看到有人总是想跑满带宽或升级带宽,不明白背后的需求是什么,要求持续高带宽的场景非常少,带宽到达一定速度后边际收益递减,与其追求带宽上的快,不如优化网络延迟,买个延迟更低的机场更香
1
deplivesb 2023-06-29 14:22:37 +08:00 1
|
2
shyrock 2023-06-29 14:30:05 +08:00 1
那么 N1 刷 OpenWRT 是不是最佳旁路有选择?
|
3
fatekey 2023-06-29 14:31:39 +08:00
软路由和硬路由的区别一般就是能不能通过装软件吧,一个硬路由刷了 openwrt 就变了软路由。。我觉得稳定性这玩意还是看固件水平,很多所谓的官方固件未必比纯净 openwrt 稳定(当然装多了软件那就难说了)。至于针对网络层有专用硬件设计的路由,那玩意不是家用的吧。。。
|
4
kaedeair 2023-06-29 14:38:24 +08:00 1
@fatekey #3 软路由是指没有硬件实现 nat 、pppoe off load 、交换机等网络协议或功能的路由器,也就是说所有网络操作由 CPU 完成,而不是基于固件区分
|
5
liulongquan 2023-06-29 14:49:15 +08:00 1
旁路由一点都不香,需要电脑开代理
python 的 pip 会直接报错 还是无感的透明代理香,拒绝旁路由 |
6
YGBlvcAK 2023-06-29 14:50:53 +08:00 via Android
不稳定?挂掉?错错错,不会玩而已!
|
7
metalvest 2023-06-29 15:13:22 +08:00
@liulongquan 旁路由需要电脑开代理?这是哪个平行空间的旁路由……
|
8
poporange 2023-06-29 15:14:13 +08:00
一直 N1 主路由
|
9
sl0000 2023-06-29 15:42:05 +08:00
非侵入式的 OpenWRT 透明网关代理配置与一键脚本
非侵入式的 Debian11 透明网关代理配置与一键脚本 非侵入式网关 Podman 容器透明网关代理配置与一键脚本 |
10
lemonTreeTop OP @fatekey 软路由系统可以跑在许多硬件上,也包括硬路由。家用路由器在网络层上有硬件支持,所以硬路由即使在 cpu 性能比软路由差很多,在一些网络性能指标上硬路由也比软路由表现得好
|
11
lemonTreeTop OP @liulongquan 为什么说旁路由是俗称,你这样理解软路由我都不能说你错
|
12
lemonTreeTop OP @deplivesb 总体来说,还是硬路由比软路由稳定,硬路由的固件比较简单,软路由扩展性强,追求扩展性的同时也在牺牲稳定性,反过来说,软路由不追求过多扩展性,它也可以视为可接受的稳定性,如一些精简 openwrt 系统
|
13
AlexPUBLIC 2023-06-29 16:23:02 +08:00
旁路由经常有一些莫名其妙的问题, 我用的 aqara 的摄像头,旁路由下就无法下载固件升级
|
14
maybeonly 2023-06-29 16:24:09 +08:00
作为入门的话,旁路由或许还好啦
或者某些条件受限,比如路由器房东的 /搞坏网络会被老婆要求跪主板,那也就旁路由吧 时间长了还是主路由的好,流量自然流过,对下游设备完全透明,能实现的东西也更多 不稳定?最大的可能是操作不当,我家核心路由不停电都不重启的 性能? n100 来一个,路由场景没有什么 hold 不住(过剩了) 至于网络分层……运行在 ip 层有什么行,完全可以。 所以,“多数用户”到底是谁啊。 最后那句倒是很同意。 |
15
MeteorVIP 2023-06-29 16:54:44 +08:00 via iPhone
主路由 openwrt ,6 个千兆口,旁路由 openwrt ,1 个千兆口。主路由就上网,旁路由就折腾,随便折腾。
就我说软硬路由都稳定。 |
16
Sekai 2023-06-29 16:57:00 +08:00
膀路由 算了吧
|
17
hfl1995 2023-06-29 17:26:03 +08:00
@AlexPUBLIC 使用的 clash 翻墙吗,建议打开,绕过中国大陆 ip ,只把需要翻的 ip 走 clash 代理,其他都不走。
|
18
hfl1995 2023-06-29 17:27:37 +08:00 1
我看别人是实践都是双软路由,ROS 主拨号和分流,openwrt 科学上网,有自动脚本,遇到故障自动切网关和 DNS 。
|
19
Donahue 2023-06-29 17:31:53 +08:00
@shyrock 现在有 4G 内存的 rk3566 盒子, 可以替换 N1 了,使用上没多大区别,优点是内存跟硬盘比 N1 大,缺点是目前固件还不够多
|
21
8355 2023-06-29 18:05:46 +08:00 1
旁路由真的不好用 体验十分垃圾
主路由简直不要太爽 直接扔弱电箱跟光猫放一起直接拨号接管 通过规则判断分流策略 屋子里不需要贵的路由器直接 ap 就可以覆盖又好 路由不想扔就换 ap 模式 组 mesh 即可 |
22
moxuanyuan 2023-06-29 18:30:10 +08:00
@Donahue #19 rk3566 盒子比 N1 价格贵一倍有多吧。。旁路由用 n1 ,还是 yyds ,我一年多没关机了,除了停电
|
23
huaweigg 2023-06-29 18:34:37 +08:00 1
之前用 rk3568 跑 openwrt ,openclash 可配置性不满足我的需求,需要定期手动更新维护。换成 m2 mac mini + 两个 usb 网卡加上 surge 之后基本不用操心了。
|
24
Jirajine 2023-06-29 18:55:36 +08:00 3
旁路由是非常垃圾的 trick ,去程回程路径不同、ipv6 很难正确处理,旁路由就是最糟实践。
但把所有网络相关服务都部署在一个 openwrt/opnsense 这种“路由器”系统里也不是特别好的做法,防火墙规则混成一团、维护不便等。 这里提供有两种更优的思路,还有其他的欢迎补充: 1. 使用 layer 2 防火墙,也可以称为“软交换机”,比起软路由,这台服务器不处理路由,而是通过虚拟交换机( aka 网桥)在二层操作内网的流量,linux 下通过 nft/ebtables 把选中的流量劫持到网络栈中,后面就可以自由处理。 2. fake-ip 结合静态路由。如果使用 fake-ip 的方案,可以在主路由上添加 fake-ip 的 ip 段的静态路由到运行服务的服务器上。 |
25
lnkn 2023-06-29 18:59:31 +08:00
我是直接当主路由用了,无线路由器仅做无线
|
26
smy14520 2023-06-29 19:06:37 +08:00
@liulongquan 为什么要开代理,不是网关设置旁路由么
|
27
liulongquan 2023-06-29 19:10:46 +08:00
|
28
smy14520 2023-06-29 19:16:18 +08:00
@liulongquan 我是在需要的设备上设置网关地址为旁路由地址,软路由挂了也只会是我自己的设备挂了,不影响家人
|
29
rrfeng 2023-06-29 19:21:22 +08:00
第一句就大错特错。透明代理网关什么时候必须是旁路由了?
另外企业级的也不是没有。 性能不够?加钱。 |
30
zhangyq008 2023-06-29 19:54:10 +08:00 1
折腾过这些,最后还是用上了 mac mini + surge 省事,简单,好用
|
31
Moeblack 2023-06-29 20:33:13 +08:00
现在一直用旁路由,主要是主路由没法解决爸妈看电视的需求。。。。
|
32
demoshengxw 2023-06-29 20:38:18 +08:00 via iPhone
对我来说软路由的作用就一个,透明代理
|
33
billytom 2023-06-29 20:54:50 +08:00 via iPhone
@zhangyq008 想问下,这会 Surge Mac 的路由性能可以跑满千兆了吗?很久前 Surge Mac 很弱最多只能跑 300mbps 以下
|
34
iamOldMaster 2023-06-29 21:22:26 +08:00
雅典娜跑千兆+AX5JDC 刷 op 旁路由,实现代理需求
|
35
moxuanyuan 2023-06-29 21:31:59 +08:00
@iamOldMaster #34 我是雅典娜+n1
|
36
lemonTreeTop OP @zhangyq008 #30 mac mini 逃不掉软路由的宿命
|
37
moxuanyuan 2023-06-29 21:34:44 +08:00
@Jirajine #24 对于大部分人用旁路由,稳定性和性能绝对是没问题,比你提供的方案还简单。。。家用雅典娜+n1 旁路由 1 年多,没出过一次问题。。
|
38
Donahue 2023-06-29 21:36:24 +08:00
@moxuanyuan 前几天有人卖 4+32G 的 rk3566 盒子,接口比较少就是,拿来跑一些脚本挺好的,内存能大点。旁路由倒没什么区别,都一样用
|
40
cowman 2023-06-29 21:44:43 +08:00 via Android
我愿意称之为家用实用配置方案 https://blog.xuegaogg.com/posts/1952/
|
41
missdeer 2023-06-29 22:04:47 +08:00
@zhangyq008 pf 不香吗,何必花这个钱买 surge
|
42
titanium98118 2023-06-29 22:34:39 +08:00 via Android
我一直是用 openwrt 做主路由,从 12.09 开始用到现在的 23.05 ,没遇到什么不稳定。最近用 hyperv+r5c ,两台 openwrt 做 vrrp 故障迁移,只要不作死同时两个一起折腾,家里网都不会断。
|
43
helllkz 2023-06-29 22:42:10 +08:00
旁路由确实没啥意思,还做配置,直接主路由透明代理不好么
|
44
arfaWong 2023-06-29 22:43:17 +08:00
ros + debian 网关,网关里面装 sing-box ,开启 clash api
|
45
lemonTreeTop OP @maybeonly #14 多数用户我指的是需要用到代理服务的用户。额,在折腾软路由容易影响其他人的网络访问,这其中有人的原因也有软路由的原因
|
46
bobryjosin 2023-06-29 23:54:15 +08:00 via Android
ros+openwrt 旁路由,俩路由做 vrrp ,掉线自动切换,在虚拟机里面开了俩 openwrt 掉了就换另一个,完全不干扰,rb5009 这玩意 uptime 已经快半年了,很稳,都可以忽略它的存在了,旁路由可能拗口,叫旁路网关比较合适。
至于 ipv6 流量无法接管,你可以 nat ,旁路由宣告主路由就行了 当然我倒是不推荐 ipv6 nat ,或者更直接一点,不需要设置旁路网关,直接在主路由把 cn ip list 写进路由,排除 cn ip 其他 ip 去旁路由就解决了,旁路由挂掉也不影响。 不稳?不好用?不会用罢了,说白了这东西会玩的人很稳,没能力玩出花,得出结论为这玩意垃圾。当然也不排除觉得这样玩很复杂,单纯只想省事的。 |
47
Jirajine 2023-06-30 00:26:59 +08:00
@moxuanyuan 只是你忽视了问题,“旁路由”要想正确配置可一点都不“简单”。dhcp 怎么分配? ipv6 怎么处理?动态前缀? dns 泄漏怎么解决? nat 类型、涉及 upnp 端口转发、打洞呢。还有回程包的路由会怎么走你知道吗?
这三种方案的共同点是在一台单独的 host 上部署透明代理服务和相应的策略路由/防火墙劫持规则,除此之外,软交换机方案只需要创建一个 bridge 把连接主路由和其他设备的端口桥接到一起并添加几条 ebtables/nft 规则劫持以太网流量到网络栈; fakeip 方案只需要在主路由或其他设备上添加一条静态路由;而“旁路由”方案处理好以上所有的事情是最困难的。 |
48
Jirajine 2023-06-30 00:30:59 +08:00
@bobryjosin 因为“旁路由”确实是垃圾,正常环境下都没人用的不符合 rfc 标准的 trick 。只是一些半瓶子水的博主出了一堆教程然后小白按图索骥罢了。
|
49
Ming5Ming 2023-06-30 02:39:29 +08:00
透明代理的分流很不方便, 所以不怎么用...
|
50
zhangyq008 2023-06-30 07:37:05 +08:00 via iPhone
@billytom 内网设备我用 iperf 测过,可以跑到 900 多,我觉得没啥性能问题
|
51
zhangyq008 2023-06-30 07:38:50 +08:00 via iPhone
@missdeer 这种问题没有意义,因为我是苹果全家桶,有 mac mini,手机也用 surge,对我来说这是最好的方案
|
52
lemonTreeTop OP @Ming5Ming 透明代理网关很方便,分流规则简单点就好了,国内直连,国外代理,终端无感知
|
53
suixn 2023-06-30 08:28:46 +08:00
对我来说主要是旁路由 ipv6 的问题不好解决。另外 win 系统 ipv6 dns 优先级高。导致 fake ip 用不了
|
54
neroxps 2023-06-30 09:06:02 +08:00 22
“旁路由”,在传统网络上是不存在这种说法,只有单臂路由,策略路由。
其实什么路由都无所谓,能解决问题就是好路由。 每个人也有适合他自己的解决方案,自己觉得好就行了。 最佳实践,这个看哪个角度了,例如你觉得硬路由做主路由,其他需要爬的机器采用修改网关 dns 来实现出墙功能,那么你觉得这样方便维护,那么是没问题的。 我最早折腾是搞 openwrt 做主路由,当年还没有什么插件,都是自己手动搭的,根据 IP 表分流,dnsmasq+ipset+ iptables+ss-libev ( redir )+pdnsd 组合来解决 dns 污染和分流代理 但是这种组合维护特别不方便,ss 的服务更新,分流出问题了调试麻烦(组件太多) 后来 surge 出现后,陆陆续续的 ios 小火箭 qx 等基于规则的代理工具也出现,clash 也同步出现,逐渐成为了主流工具。 我也把 openwrt 的代理工具换成了 openclash 。 优点是:有 web 面板,切换节点,日志查看都非常方便。 缺点:openclash 想做 clash 的 web ui 客户端,想把 clash 的配置全部丢到 web 上方便用户配置和修改,确实做的很棒,但这样脚本的代码量非常大。试过几次因为 openclash 更新订阅的时候可能因为网络抖动问题下载下来的是空文件,但他不会校验(现在不知道会不会)。导致 clash 直接不启动了,不启动他也没有清理 iptables 等配置导致直接断网。(现在应该修复了?没再用了) 后来了解到 Mikrotik RouterOS ,就入了一台弱电箱神器。开始玩 Mikrotik 系列路由 对于本来就是学网络的人,routeros 其实比较适合,界面直观,配置概念完全是按照网络概念设计,如果你熟悉网络通信原理,熟悉防火墙配置,那么玩 ros 其实并不难。 但换了这个硬路由,爬墙怎么搞呢。我一开始也学大家一样,做“旁路由”(其实就是多层 NAT 路由),那么根本没法解决 openwrt 单点故障的问题。而且 NAT 转换效率,根本没有发挥硬路由的优势。 后来搜到的解决方案都是说例如你某个机器要爬,可以让 dhcp 服务器根据不同的 mac 地址分配不同的网关,或者是手动设置网关和 dns 。 我觉得这种方案太麻烦了,例如我某个设备今天突然需要访问一下 google ,只是突然需求,我还得电脑开机路由上配置,即使 Mikrotik 有手机客户端,我也需要等待 dhcp 生效,或是手动配置网关和 dns 。 我认为这个需求能直接从主路由上解决他们,后来也了解到各种代理工具都在用 faek-ip 方案。理解了工作原理之后,我就针对家里现有的网络拓扑进行修改。 最终采用 硬路由+dns 分流+fake-ip ( shellclash ) 的方案: 优点: - 完美的分流:分流完全取决 dns 规则,只要匹配规则才能拿到 fake-ip ,fake-ip 的流量才会跑到 openwrt 那边,国内流量是直接从主路由就出去了。根本不会到 openwrt 那边。 - 网络性能:所有流量都先到主路由,主路由根据路由表进行流量转发,这是硬件路由的强项,所以基本不会有性能消耗,即使是最垃圾的 tplink 家用路由器,他也能完美的完成这个需求。因为得益于 fake-ip 方案(出自 https://www.rfc-editor.org/rfc/rfc3089 ),出墙的流量不需要获得真实的 DNS ,也不需要等待 DNS 答复,能以最快的速度封装 IP 层后发起访问。 - 维护便利性:因为只采用 dns 分流,所以只需要关注 dns 分流情况即可,拿到 fakeip 的流量才会跑到 openwrt 那边去。如果 dns 炸了,脚本能够自动检查并切换主路由的 dns ( Mikrotik 带脚本功能) - 完美兼容 ipv6:因为对于局域网设备而言,他们只有一个网关就是主路由,所以和普通的网络是一样的,ipv6 自然就不受影响,而爬墙流量,因为 dns 服务器回答 fake-ip ,根本没有 ipv6 地址,所以自然也不受影响。 - 自动愈合( Mikrotik 独有):通过 Mikrotik RouterOS 的脚本功能,定期检查 openwrt dns 服务,如果出现故障,立即切换 ROS 的 DNS 上游服务器为运营商 DNS 。路由表则完全不需要管,因为运营商的 dns 不会回应 fake-ip 给你。 缺点: - 依然存在(非主路由的)单点故障:因为 DNS 分流靠第三方服务,所以如果 DNS 服务器挂了,会导致整个网络的域名解析出现问题。我做法上面也说了,如果出现故障,立即切换 ROS 的 DNS 上游服务器为运营商 DNS 。 - 对非网络专业人员而言,有配置难度。(其实所有透明代理都需要解决 dns 和路由问题,只是人家把这个过程放到 openwrt 脚本里帮你自动配置而已) 这方案我已经用了快两年,几乎 0 运维。这也是我个人认为翻墙网络的最好实践 |
55
oovveeaarr 2023-06-30 09:16:04 +08:00
旁路由真的属于半吊子操作...软路由的好处没吃到多少,复杂度+不稳定性倒是拉满了。。。
|
56
sun82kg 2023-06-30 09:21:38 +08:00 3
@neroxps 我是 ros+naiveproxy 。方案其实和你类似,但感觉比你更简单一点,https://hub.docker.com/r/tonysun0319/naive
|
57
oovveeaarr 2023-06-30 09:24:20 +08:00
@neroxps 其实 FAKE IP 也很 Dirty ,它破坏了网络的完整性...兼容性不一定好的同时,目的地地址被改写了,如果单纯是用来代理没什么问题,但是很多其他的内容也会造成影响。
如果是我设计,增加这一层额外的复杂度是我想要避免的,既然转发了 DNS 直接路由就行了,然后用通常的 REDIR 等处理方式就行。 甚至更进一步,这一步甚至可以直接在主路由中完成,至于怎么去代理只是加一条策略路由的事。 |
58
shijingshijing 2023-06-30 09:26:58 +08:00
先把电信宽带升级到 1000M ,买的梯子稳定跑 200M 以上再谈性能缺口,现在软路由性能一般都是过剩的,这种情况下,稳定性和灵活性反而是实际应用考虑的重点。
|
59
thereone 2023-06-30 09:37:32 +08:00
@Jirajine dhcp 走主路由 ipv6 主路由分配当然 ipv6 跳墙的不清楚没做过,dns 泄露单独部署一台 dns 服务器或者旁路部署 mos smart adguardhome 都行,NAT 类型主路由做不就行了。upnp 一样主路由做打洞同样的。
你的问题都是在旁路由做了 NAT 才会出现,真正的问题点反倒是没有提出来。op 的旁路由单纯路由非 NAT 模式正常对普通的数据包又不会有三层及以上的报文的改变,会变的只有源 mac 地址而且只会在有上传的时候才会变。因为过了一个网关 网关自然会对源 mac 地址修改。当开启了过墙插件才会将整个数据包修改成由旁路由始发的,此时源地址为旁路自己目的为过墙服务器的 ip ,这个和你的透明网关是一个样的。 旁路由真正的问题在于终端上传经过旁路由转发 mac 地址改变,上到主路由就会发生 1 个 ip 对应的 mac 地址在不停地发生变化,这个对于主路由有严格模式的 ip 和 mac 一一对应才能上网的会造成无法正常访问国内网站而可以访问国外网站。 当然这个一般主路由是没有这个限制的。 相反透明网关容易出现单点故障除非做两台及以上的同时还要开启 stp 阻断一条链路,要不然就是在下层设备和主路由之间做链路聚合才好避免。而旁路由和主路由起个标准的 VRRP 就可以避免因为折腾旁路导致断网,如果账号支持多拨也可以旁路由也拨号做到真正的故障无感切换。 |
60
xiamy1314 2023-06-30 09:41:03 +08:00
花里胡哨,一个 op 就够了。玩 docker ,openclash ,adguardhome 什么的,几年了不断电不重启。完全满足日常需求。当然初期还是要折腾下的。
|
61
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 |
63
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 直接出去。 |
64
archxm 2023-06-30 10:52:06 +08:00
家里人经常网购的话,还是以稳定靠谱为第一考虑点
|
65
cocomiko 2023-06-30 10:59:02 +08:00
@neroxps 我这里没搞 dns 分流,我是直接在 ros 上设置 53 端口转发,把需要翻墙的机子加入名单里,只有名单里的机子才会转发到 op 的 dns 服务器上,这样我可以在 ros 上随意指定一台 ip 是否翻墙,而且是实时的,但是很少看到别人使用这种方式,不知道这种方式有什么不好,我自己用了一年多了,觉得挺方便的
|
67
msvcr110 2023-06-30 11:12:19 +08:00
主路由从换成华硕换成 TP Link 之后,旁路由就出问题了,还要另外加 iptables 规则。但是 xbox 还是 NAT 出问题,打算弃用旁路由了,花点小钱买个 x86 拨号算了
|
68
zmcity 2023-06-30 11:19:23 +08:00
旁路由要配合 fakeip+静态路由做。
这样可以保证去回程一致。 |
69
neroxps 2023-06-30 11:37:52 +08:00
@shijingshijing 其实软路由主要是小包并发和多线程问题。但是这些问题一般不会出现在家庭网络里。
|
70
neroxps 2023-06-30 11:45:20 +08:00 1
@cocomiko 这样的做法就是一刀切,爬墙的机器如果连国内的流量依然是要跑到 openwrt 。例如我某个机器上跑 了 docker 里面有 qbittorrent 和 emby 。那么 emby 搜刮的时候需要爬墙,但 qbittorrent 流量跑到 openwrt 会损失性能,这样就很麻烦,需要对 qbittorrent 做 macvlan 分配一个独立的 IP 给它。多了一层 macvlan 对设备性能也是一种损耗,维护复杂度也增加了,当然这种损耗和复杂度不值一提,但这是因为网络拓扑的问题而导致的。那么为什么不直接在拓扑上解决这种需求?如果我维护的还有其他机器,那么维护难度就增加了。最直接的方案还是基于目的地分流,这个流量是要跑到梯子的,就跑到梯子,是直接出去的,就直接跑出去。
|
71
Donahue 2023-06-30 11:46:49 +08:00
@shyrock https://github.com/xiaomeng9597/OpenWrt/releases 这有个插件挺全的,可以加群 736056829 玩
|
72
Jirajine 2023-06-30 11:49:44 +08:00
@thereone dhcp 走主路由就无法处理 ipv6 ,因为 RA 只能广播自己作为默认网关。不处理 ipv6 要么关掉 ipv6 要么出现泄漏,因为 ipv6 会直连。
内网多了一跳会导致多种问题,比如 nat 打洞、upnp 端口转发的去回程流量可能会走不同的路径,这部分流量可能会也可能不会被代理。去回程路径不同也会导致如你在旁路由上设置防火墙规则,上行生效下行就失效了。 以及“旁路由”就是一台普通服务器,你要是这里也用 openwrt 那还不如直接 openwrt 主路由 all in one 。 “单点故障”阻断链路是应有的行为,代理挂了就应该代理流量断网,而非所有流量静默的直接泄漏出去。而透明网桥对三层网络是透明的,你想移除他只需要把网线一拔,直接插到主路由上,网络自然恢复默认状态。 |
73
KKLeon 2023-06-30 11:51:04 +08:00 via Android
@8355 说旁路由体验垃圾的还是自己没弄明白,我的 n1 旁路由几年了,稳定的一批。比红米 ax6 刷 openwrt 还稳
|
74
neroxps 2023-06-30 11:57:37 +08:00
>> 这些用户搞更复杂的网络,他们收益其实很低,除了能自娱自乐,回帖秀下优越感之外,对网络改善效果非常少。
这样说,一切以需求出发。相信弄更复杂的网络用户并非为了自娱自乐,每个人也有自己需要解决的痛点。 只是楼主在谈论最佳实践,站在网络的角度,每个人有不同的理解。 对于局域网里跑 PCDN 和 PT 的用户一台逻辑设备混合各种业务,基于源 IP 地址的分流(手动修改网关和 DNS )在我看来,并非最佳实践。 网络的事,交给网络设备去做。docker 划分 macvlan 分配多个 IP ,这种做法的确可以解决需求,但我看来,并非最佳实践。 |
75
byte10 2023-06-30 12:00:57 +08:00
@liulongquan 少年 你是不是 用错了。旁路由也是一样的使用的啊,也是无感,旁路由设置强制 DHCP ,所有的设备的网关自动变成了 旁路由的网关。
|
76
neroxps 2023-06-30 12:01:43 +08:00
其实我这套方案,很早恩山就在玩,只是人家用的是 ikuai DNS 分流功能 https://www.ikuai8.com/zhic/ymgn/lyym/lkfl/ea195/75960.html ,ikuai 是支持设置 DNS 域名匹配后,把流量转发给另一个机器。这种配置简单。
缺点就是无法动态更新规则库(当然你可以手搓脚本 用前端 API 操作更新。) 优点就是配置简单 只是很多人不喜欢用 ikuai ,因为有后门嫌疑。 |
77
lemonTreeTop OP @neroxps #74 嗯嗯,不冲突。如果有这样的需求,可以给大家提供方案参考挺不错的,感谢分享
|
78
6bsLo69Qdu3RPY4c 2023-06-30 12:14:56 +08:00
openwrt 运行时间 24d 13h 9m 46s
|
79
Terminl 2023-06-30 12:15:15 +08:00
旁路由器才是最优解,易于维护。可以避免和宽带师傅扯皮。
|
80
Bluecoda 2023-06-30 12:16:19 +08:00
传说软路由的 ping/游戏延迟没有硬路由那么稳定,这是真的吗?比如要玩一些低延迟的 fps 游戏
|
81
thereone 2023-06-30 12:37:33 +08:00
@Jirajine 旁路有需要设置的防火墙规则?就是一个代理用的。“比如 nat 打洞、upnp 端口转发的去回程流量可能会走不同的路径,这部分流量可能会也可能不会被代理” 是不可能来回不一致的,三层来看代理和非代理的源目 IP 都不一样的怎么可能会来回不一致,非代理的源目 IP 又不会变 从终端出去的源 IP 过旁路又不会改变那自然就和普通访问一样了,代理了的源目就变成了旁路的 IP 了回也是先回旁路 再从旁路转发到终端。过不过代理不就是看 dns 解析和代理的方式。国内的 IP 不过代理的自然就直接转发走了,过代理的就会旁路处理后源 IP 会变成旁路的是不可能直接转发给终端的。
基本要做限速的或者啥的规则只需要在主路由上面做,对于主路由来说过旁路由的除了 mac 地址变了基本就没有区别。硬要说的就是 ttl 和 fcs crc 这些改变了。 “” “单点故障”阻断链路是应有的行为,代理挂了就应该代理流量断网,而非所有流量静默的直接泄漏出去。而透明网桥对三层网络是透明的,你想移除他只需要把网线一拔,直接插到主路由上,网络自然恢复默认状态。 “” 你没有看懂我写的单点故障是啥我说的不是代理的问题,而是设备单点故障,你的透明网桥设备挂了还要手动拔插网线更换, 主路由--透明网桥---交换机?我不清楚你的透明网桥后面有没有交换机 正常的:主路由-----透明网桥------交换机,要想透明网桥挂了那就要两个透明网桥同时接在主路由和交换机之间,同时开启 stp 阻断一条链路,要么就是主路由和交换机做链路聚合两根网线捆绑成一根,这样才能保证某一个透明网桥挂了也不影响整个网络。 而我上面写的 VRRP 是旁路由挂了断电了,dns 和网关会自动迁移到主路由。完全不用人去干预的。甚至旁路由你也可以写个脚本检测是否能过墙,不能过那就直接自动切换回主路由。更高级的就是旁路由也拨号作为备用链路或者分流链路,哪怕主路由挂了也不影响整个网络。还高级的用法就是两台都是 op 路由内部部署负载均衡同时心跳检测 可以随机或者指定走某条链路。 |
82
neroxps 2023-06-30 13:07:01 +08:00 via iPhone 1
@Bluecoda 游戏一般是小包,而硬件路由简单的防火墙策略情况下,小包直接由芯片处理转发的话,效率肯定会比软路由的软件转发快,至于快多少。对于你是否有帮助,取决于你当前网络的小包转发量。
例如有些人什么业务都不跑,就玩游戏,路由只需要处理你的游戏 udp 小包转发那么肯定没问题。 但如果是家里跑了很多业务,小包大包各种流量都有,同等情况下,硬件转发必然比软件转发效率更好。 |
84
tywtyw2002 2023-06-30 13:09:23 +08:00
看标题,以为这帖讨论的是 vyos ,routeros ,pfsense ,海蜘蛛之类的东西呢。
结果 openwrt+代理。。。 撤退。 |
85
Jirajine 2023-06-30 13:15:51 +08:00
@thereone 比如说你的设备通过 upnp 让主路由开了一个端口转发以接受入站连接,而你的设备回复的包会走旁路,这个包可能会被代理(取决于地址与规则)。去程回程的路由路径不一致也会导致比如限速、抓包等无法处理回程流量,这种非标准的结构也违反了更多应用的 assumption ,比如 nat traversal 。
你说的单点故障问题,恰恰与实际需求相反。作为一个代理工具挂了自动切换到直连泄漏所有流量是最糟糕的行为,真正需要的是 kill switch , 几乎所有正经 VPN 都提供的特性: https://www.expressvpn.com/features/network-lock 而且透明网桥不需要折腾路由,对三层透明。无论公司还是别的地方,只要把它接入进去,下面的所有设备都能自动代理,拔掉自动恢复,客户端和网络侧都不需要任何修改。dhcp/地址分配/dns/ipv6 统统都不需要关心。 |
86
thereone 2023-06-30 13:30:27 +08:00
@Jirajine 透明网桥这个也一样的有这个问题难道你没有发现?还是你觉得透明网桥是怎么处理代理的呢? “这个包可能会被代理(取决于地址与规则)” 这个你的透明网桥就有办法避免?如果可以避免那你说透明网桥的处理代理数据包的原理是啥?不用修改报文不修改源 IP ?判断哪些需要代理的不是一样要地址与规则。相反你这个插入到网络中还会导致不需要代理的被强制代理,而且一旦设备故障了也不会自动切换和自愈。甚至直接导致断网,虽然家用没有多大的问题但终归是会断网要拔插网线。
|
88
Jirajine 2023-06-30 14:01:00 +08:00
@thereone 当然可以避免,因为不同于“旁路由”,透明网桥是能看到所有流量的。所以可以直接使用 connection track 来排除掉入站方向连接。
“自动切换和自愈”再说一遍这是 anti-feature ,故障了我需要自动断网而不是偷偷直连。 这并不会导致不需要代理的设备被强制代理,如果是公司这种 portable 的场景,只有插在透明网桥下面的设备和交换机/ap 才会代理;如果是家用,只有防火墙规则选择的设备( ip 地址或 mac )才会劫持到网络栈处理,其他的流量则表现为一个正常的二层交换机转发而已。 并且你说的故障只有这个 host 完全挂掉(硬件损坏、kernel panic )才会导致完全断网,如果只是代理服务挂掉,那只有代理无法使用,原本直连的照样可以直连,因为它只是一个“软交换机”而已,bridge 是跑在内核里的。 弄个 alpine 这种 diskless 安装的稳定系统,运行时连 sd 卡/硬盘都不需要,系统挂掉的可能微乎其微。 |
89
KKLeon 2023-06-30 14:07:54 +08:00 via Android
@8355 不是,我用的全局模式,所有设备的网关都已经自动设置为旁路由地址,稳定性这个也是经过了考验的,n1 稳定运行几年了还没出过问题,除非我自己折腾新固件才会重启。我前段时间本来是买了个红米 ax6 ,想着一台设备直接替换掉原来的 newifi3+n1 组合,但是到手后发现,单纯的红米 ax6 还是会有问题,要么是刷 op 固件的话无线跑不满千兆(开源驱动的问题),要么原生固件装 shellclash 的话,遇到过内存不够会重启的情况。另外红米 ax6 用油管测速的速度比 n1 小 50%,所以现在我还是红米 ax6 做主路由,n1 做旁路网关,用的很舒服
|
90
lemonTreeTop OP @Bluecoda #80 打游戏需要 clash 开启 tun 模式,并切换网络栈为 Gvisor 。延迟没有变化,如果有可能是几毫秒吧
|
91
thereone 2023-06-30 14:20:06 +08:00
@Jirajine 那不是一样的,旁路由一样可以决定哪些需要代理哪些不用直连这个没有区别。
你说的“故障了我需要自动断网而不是偷偷直连。”这个才是没有多少人有这个需求。大部分人要的是不断网。不管怎么折腾旁路由都是不会断网的那种。代理挂了一样不能访问,这个没有问题啊旁路由代理挂了如果 VRRP 里面没有追踪代理本来就是不切换,墙外网络本来就是会不能访问因为代理又没有自动关和取消。所以你这个解决了设备如果挂了电源坏了这种能保证网络不中断吗?问题就在这里你的始终是串在网络里面的没有解决透明网桥 host 挂了不需要手动操作的方法 |
93
8355 2023-06-30 14:26:28 +08:00
|
94
maybeonly 2023-06-30 14:30:45 +08:00 1
@thereone 来回路径不一致可能还是小事,端口映射确实可能会出问题:
假设内网用户是 192.168.100.200 ,主路由 192.168.100.1 ,旁路由 192.168.100.9 映射(包括各种映射)了 8888 端口到外网端口 198.51.100.100:8888 。 此时有来自 203.0.113.2 的用户访问了你的公网端口,然后他给你发了一个包。 203.0.113.2:12345->198.51.100.100:8888 进行 nat 以后,通过主路由转发到了客户机,到这里还没问题。 然后客户机需要给他回包: 192.168.100.200:8888->203.0.113.2:12345 这时候这个包首先被发送到旁路由。这个时候说不定(看策略)就被走其他路径“劫走”了, 然后可能通过 vps 的出口发给了对端的机器,对端看起来数据包是这样的: 192.0.2.33:27428->203.0.113.2:1234 这数据包哪儿来的……于是就扔掉了,通信失败。 单点故障的场合,不认为家庭环境有那么多需要热备的,要坏的话主路由一样会坏,主路由更需要热备吧……光猫也可能坏,怎么热备呢?局方给你套个 SDH 大圈圈吗……不可能的吧……连链路都只有一条的说…… 虚拟链路的话……就只有一条吗……就算只有一条,主路由一样可以临时禁用(如果这是希望的结果的话)。不要默认旁路由容易坏,更不要默认特殊功能的设备就容易坏。如果设置正确、运维得当是没问题的。当然,如果是刚上手的学习阶段,还是可以用旁路由练手的。 接下来就是性能,转发性能确实比不上硬件但是在家用场合下可以忽略。2023 年了,就算还在用 j1900 ,nat 性能会成为问题吗?小包转发确实有可能会没法千兆线速,但是家庭网络您在干啥会有那么多小包?家庭网络最大的 cpu 开销,一是 pppoe ,二才是加解密。pppoe 是个跟不上时代的古董协议,特别耗费资源。再说,升级个设备其实也没多少钱,考虑下宽带费用电费可能还有其他按月计价的费用……设备成本可是可以摊销的。 透明网桥我实现过,整体上还不错但是有点其他问题,现在 broute 表都被拿掉了,以后不知道该怎么搞。可是那也是条件所限拿不到路由的时候才用的,拿得到路由的话用路由舒服多了。企业应用也一样,管理设备要串行接入网络的话要物理操作要断网,但是路由指过去的话就可以远程操作,也可以屏蔽,还可以部分应用。 至于配置方便程度就更不要说了,拿着主路由权限可以下发各种东西,你要给多少设备设置网关啊?我家的电脑×n 、手机×n 、pad 、电视、虚拟机×n ,都要一个个爬上去设置 dns 吗……我家下发的 dns 的 ip 都是一样的,但是会根据策略拉到不同的服务,返回的东西也可能不一样,这些用旁路由……不是做不到,而是,还是算了。 最后,多线上联(不同运营商多条宽带)这一条,旁路由被薄纱。 |
95
KKLeon 2023-06-30 14:30:56 +08:00
@8355 是这个意思。像楼里经常推荐的 N1 做旁路网关,随便搭配个拨号的硬路由,整体稳定性应该非常可以,成本也不高。N1 内存也够大,想多跑点轻服务也绰绰有余。
|
98
thereone 2023-06-30 14:44:39 +08:00
@maybeonly 所以旁路由可以拨号和主路由做主备啊,我上面也说过了的。谁说要手动配置设备的啊,都说了起 VRRP 协议 下面的自动获取就完了,不需要的过强的在过强软件里面排除掉不就行了,再或者直接在 iptables 里面操作。
还有多线和旁路由有啥关系,你这说的什么看都看不明白。 |
99
maybeonly 2023-06-30 15:07:28 +08:00
@thereone 主备实现不难,关键是意义在哪儿……如果旁路由这些都能干了,他还安心当个旁路由吗……为什么不直接升级为主路由呢,网络更简单清晰。当然,如果作为主路由备份是为了过渡到主路由的话,我双手赞成。
多线场景是极限自定义的场景。只有作为主路由,才好充分利用多条宽带的能力。因为流量是双向流过的,才好建立 conntrack 。 简单的说,如果有个 vps ,然后自己有两条宽带 a 和 b ,再乘上 v4 和 v6 ,就变成 4 条线路了。 这一点旁路由完全没办法决定自己出去的直连数据包从哪里出去……如果要同时用两条不同的线路和远端建立两条链路做主备,旁路由最多最多只能一个 v4 一个 v6 然后让主路由写路由表了吧。 但是在主路由上直接搞的话,一切都可能实现。 以及前面说过的,端口映射,也需要在主路由上有相对复杂的配置,这一点旁路由很可能是个干扰。 再考虑 v6 的话,旁路由就更难受了。 其实就是说,当网络结构越来越复杂的时候,旁路由需要越来越多地与主路由交互。这时候就更显得旁路由多余甚至有点难受了。 当然重复一下观点,作为学习练手,或者由于条件所限使用旁路由是很合适的。除此之外长期稳定使用特别是重度使用的话,建议直接做在主路由上。 |