F_picacho
F_picacho
发布于 2026-05-11 / 72 阅读
0
0

幸福网络

前阵子在玩 Satisfactory(幸福工厂),后面越折腾越感觉这玩意和家庭网络特别像。给定输入和输出,决定数据往哪里走,最后得到自己想要的结果。

AP、交换机、网关、旁路由……一根根网线将他们串联起来。
有时候看着甚至真有点像在摆传送带。

MVIMG_20260511_204014.jpg

起因

搬来新地方有段时间了,内网也折腾得差不多稳定了。

从一开始随便插根网线能上网就行,到现在路由、AP、NAS、旁路由一堆东西全堆上了,过程中踩了不少坑,顺手记录一下。


折腾家庭网络的起因其实很简单:我设备太多了。
每个设备都单独挂代理实在太麻烦,所以一开始只是想搞个全屋无感翻墙。

后来被同事安利开始玩 galgame,我又开始用 Steam Link 串流游戏。结果发现内网串流这东西,对网络稳定性要求比我想象中高很多,小包发得又密又频繁,网络稍微有点波动体验就很明显。

再后来又入了 NAS,问题也开始逐渐离谱。
原本的 GL.iNet GL-BE3600 网口完全不够用了,于是又补了交换机。

但设备一多,网络结构也越来越混乱。
当时家里有一个专门负责翻墙的无线路由器,还有一个专门负责内网串流的无线路由器,它们各自都开着 DHCP。
结果就是:

  • 同一个内网里存在多个 DHCP 服务器

  • 双重 NAT 到处都是

  • 设备偶尔还会随机抽风

虽然能用,但明显属于“能跑就行”的野路子方案。

后面实在受不了了,于是重新买了主网关,把整个网络重新整理了一遍,统一管理 DHCP、路由和流量。

到这里,这套家庭网络才终于算进入了我比较满意的状态:

  • Wi-Fi 下设备无感科学上网

  • 内网高速串流稳定

  • 大部分内网流量直接走交换机,减少路由压力

  • 全局由一个主网关统一控制

接下来就详细记录一下整个网络的设备和接入方案。

设备清单以及拓扑

依旧是梦到哪里画哪里...

实线有线接入,虚线无线接入

  • MikroTik RB5009UG+S+IN
    主网关 / 核心路由器。

  • UGREEN CM754
    核心交换机。

  • GL.iNet GL-BE3600
    旁路由(OpenWrt)+ 无线 AP 模式,主要负责科学上网。

  • Tenda AC1200
    无线 AP 模式,负责内网高速串流。

  • UGREEN DXP4800 Plus
    核心存储节点,同时承担部分与存储或者下载的 Docker 服务。

  • XXXX
    后面还打算补一台服务器,用来跑 PVE 做虚拟化,再通过 FRP 对外暴露一些服务。

    不过目前还没想好网络该怎么接:
    是直接接到核心交换机,还是单独接到主路由下面做区域划分。

    前者结构简单一点,后者在隔离性和管理上会更舒服。

    本来年前其实已经看好一套配置了,结果今年内存价格涨得太快,同样的配置现在价格都快翻倍了。

    只能暂时先搁置一下,等后面行情正常点再继续折腾。

需求先行

自动代理/分流逻辑

因为工作地点经常变动,所以我对网络设备有一个很明确的要求:尽可能轻量,尽可能简单。

最开始我也考虑过比较传统的方案,比如买一台 N100 小主机刷 OpenWrt 当旁路由,后面再接无线网卡或者额外的无线 AP。但实际调研下来发现问题不少:

  • 如果直接插无线网卡,大部分网卡的无线性能都比较一般,基本属于“能用,但体验别要求太高”的状态;

  • 如果额外接一个正经 AP,整体体积、供电和设备数量就会开始失控。

这和我想要的“轻量化”初衷完全冲突了。

查了不少资料后,我最终选择了 GL.iNet GL-BE3600。(同价位其实还有一个更强的 GL-BE6500,可惜我买的时候还没发售)。BE3600 本身偏向移动/便携路由器,体积做得足够小。虽然代价是散热比较一般,长时间高负载得自己加个散热底座,但它的无线规格完全够用,而且原生支持开启 OpenWrt,这点对我来说是核心刚需。

分流逻辑是照抄的安格视界的方案
https://www.youtube.com/watch?v=WwywoXPFpdw
我已经使用这套规则小半年了 实际上有一些小小的问题就是游戏方面的代理不过也后续通过其他手段解决了,后面会提到。

至此全屋科学上网的问题得到解决,但是后续使用又来了新的问题。

起初,我的部署方案是“主路由模式”。 它直接接在光猫后面,作为独立路由运行。虽然物理拓扑很简单,但因为光猫本身已经做了一层 NAT,BE3600 又进行了一层路由转发,导致整个网络形成了双重 NAT

平时网页浏览或者看视频倒也相安无事,但一到游戏场景,叠加了 OpenClash 的流量劫持后,问题就开始集中爆发:

  • 一些外服游戏的流量被错误代理;

  • Steam 联机偶尔莫名抽风;

  • 某些游戏加速器的规则与 Clash 互相打架;

  • 游戏内的 NAT 类型变得非常奇怪。

虽然理论上可以通过查看 OpenClash 日志慢慢排查,再手动补 IP 规则或加黑名单来解决,但这种修修补补的事情次数一多,维护成本实在太高了,失去了折腾的乐趣。

实在受不了之后,我干脆换了个思路:把 BE3600 改为“旁路由(旁路网关)”模式。

我将 DHCP、路由转发和 NAT 的能力全部交还给上层主路由(RB5009),让 BE3600 回归纯粹,只保留无线接入和代理能力。

这样一来,虽然看似牺牲了一点“完全无感”的体验——新设备接入无线时,需要手动将网关和 DNS 指向这台 OpenWrt 旁路由(不过这其实有优雅的解决方案,我会在后面聊到主路由配置时详细展开)。但换来的好处却是决定性的:

因为主力游戏机可以直通主路由,流量不再受到全网劫持的干扰,反而变得更加灵活(比如我只在主力 PC 上单独跑一个 Clash 客户端来处理特定需求)。各司其职之后,游戏加速器不再打架,整个网络终于迎来了久违的彻底稳定。

主网关配置

我并不是什么网络大牛,也就是懂一点皮毛,遇到不懂的就丢给 AI 让它帮我查命令/配置。

在配置这台 RouterOS(RB5009)的时候,我最开始只是用 Quick Set 把基础网络跑起来。不过我的网络环境有点特殊,不是常见的 PPPoE 拨号,而是公寓网络中心直接分配的静态 IP,本质上就是“上联已经帮你铺好路了,下面只需要把内网管明白”。

我折腾 RB5009 的核心目的其实也不复杂:把多重 NAT 和内网 DHCP 混乱的问题一次性解决掉,顺便把以前那种“每台设备手动改网关”的历史遗留问题清理干净。

一开始我走的是一条看起来很简单的路:DHCP Options + 旁路由接管

思路很简单:

  • Code 3(Gateway)→ 指向 BE3600(192.168.1.2)

  • Code 6(DNS)→ 同样指向 BE3600(192.168.1.2)

  • 打包成一个 Option Set,下发给需要代理的设备

效果也确实很“顺”:

  • 设备一连 WiFi 就自动进代理体系

  • 不需要在客户端手动配置

后来我也试过 PBR(策略路由)这条更“工程化”的路线,但最后还是放弃了。

原因说白了就三点:

  • 我大概 95% 的设备都要走代理

  • 剩下那 5% 才需要直连

  • PBR 的分流能力在这种结构里基本发挥不出来

这时候 PBR 就有点尴尬了——规则写了一大堆,但最终结果几乎永远指向同一个出口,还白白把 FastTrack 的优势稀释掉一部分。

再加上 mangle / routing mark / 排除规则这些东西一旦上来,维护成本会肉眼可见地上升,但收益却没有同步增长。

所以最后我还是退回到了 DHCP Options。

本质上就是做了一件更“懒但合理”的事:把“判断逻辑”从路由器上拿掉,直接写进默认路径里。

代价也很清楚

我放弃了这些能力:

  • 按设备精细分流(手机/电脑/IoT 更细粒度控制)

  • 按 Docker / NAS 做复杂网络隔离

  • 更高级的策略路由组合玩法

但换来的东西也很直接:

  • 网络结构变简单

  • 故障点明显减少

  • 新设备接入几乎零成本

  • 没有 mangle 乱飞,没有 FastTrack 冲突,没有规则互相打架

说到底就是一句很现实的话:

我没有在追求“最强网络架构”,我只是想要一个稳定、默认就能工作的网络。

优雅,实在是太TM优雅!

想了想没必要追求所谓的最佳实践,在家庭网络环境下这貌似就是最优解。

意外的惊喜:ROS 防火墙的“救命”日常

除了策略路由,这次折腾还让我意识到,大厂硬路由的默认安全策略有多重要。

由于我的公寓网络是网络中心集中分配的,当我打开 RB5009 的路由表时惊奇地发现,WAN 口之外居然直接动态暴露着大量其他住户的 IP 段(比如 192.168.199.x 等等)。这公寓网络不知道怎么搞的,居然把所有用户都放在一个缺乏隔离的大局域网里,这意味着大家几乎是在“赤裸相见”。

万幸的是,RB5009 固件原厂自带的防火墙策略直接帮我挡下了背后的冷枪。 从我防火墙的 Filter Rules 统计来看,尤其是那条“禁止从外网(WAN)访问路由器后台”的 input 丢弃规则,在一段时间内居然默默帮我拦截了 6000 多个恶意数据包(两兆多流量)

网游戏高速串流

除了搞定外网和 NAS,折腾的最后一环,我留给了内网游戏高速串流

内网串流(比如 Steam Link 或 Moonlight)对延迟和带宽有着近乎变态的要求。如果让这种动辄几十上百兆的局域网大流量跑到主路由甚至旁路由那里绕一圈,不仅增加延迟,还容易跟其他网络策略打架。

为了追求极致的丝滑,我用了一个最简单的物理外挂:找了一台闲置的腾达无线路由器,直接改成纯 AP 模式挂在交换机下面。

每当我需要串流玩游戏时,只需要把接收端切到这个腾达 AP 的专属 WiFi 上。此时,整条串流链路变成了:

Steam 主机-> 网线 -> 交换机 ->腾达 AP ->Steam Link 客户端

在这个结构下,庞大的串流数据流直接在交换机和 AP 之间实现了内网自循环

整个过程既不需要经过主路由(RB5009)转发,更不会惊动旁路由(BE3600)的流量劫持,它们甚至不知道有这笔流量存在。零干扰、零延迟、满带宽,哪怕工作地点再怎么变,这套“局部最优解”也能随时随地提供极其丝滑的高速串流体验。

结束

至此,这套轻量化的网络架构,完美解决了我以上所有的需求:

  • 全屋 Wi-Fi 无感科学上网: 利用 RouterOS 的 DHCP Options 搭配 BE3600 的 OpenWrt 组合拳,移动设备接入即无感分流。

  • 内网 Steam Link 高速串流: 引入闲置腾达 AP 实现流量“内网自循环”,低延迟、满带宽。

  • 解决多重 NAT 问题: 将 NAT 权限全权交还给上层 RB5009,干脆利落地终结了双重 NAT 带来的网络泥潭。

  • 解决 NAS 应用流量不可控问题: 针对 Docker 容器精准分流,Emby/AniRSS 走旁路由,PT 下载直通大网,拒绝流量内耗。

  • 解决主力游戏电脑的各种网络问题: 独立客户端配合物理双栖(随时可拔掉网线切无线备灾),让游戏加速器与 Clash 各走各的道。

后续还得研究研究怎么在这种网络环境下实现WireGuard远程回家的问题,不过这种公寓网络还是需要研究研究咋优雅组网。估计得动用我的云上服务器了。

蒜鸟 就先这样。


评论