记一次：小米 be6500pro 硬路由+n150 旁路网关方案调整

[LongLights]

我有一台 n150 主机，作为主路由稳定使用了 1 年多时间，另外有一台小米 be6500pro 路由器，一直作为纯 ap 。

n150 主机使用 pve 虚拟平台，除了安装 openwrt 作为主路由，另外安装了一台 debian 虚拟机跑了很多 docker 服务（ alist 、vaultwarden 之类），另外光猫通过 vlan 绑定实现了网络和 iptv 的单线复用，并将 iptv 直接接入局域网，方法是在 openwrt 中将 wan.43 （ 43 是 iptv 的 vlan 号）加入 br-lan 组。>>>光猫 iptv 单线复用方案详解

这个方案最大的优势是： 完全无感的透明代理，包括 ipv6 流量。配合 fakeip 模式也可实现：本地 v6 、节点 v4 时的自动 fallback 。

后来随着 debian 虚拟机的服务变多，发现偶尔会遇到轻微网络卡顿，网络满载时的波动也比较高，虽然可通过 SQM 队列优化，但其本身又会加剧 cpu 消耗。猜测还是虚拟机的资源占用导致 n150 产生 cpu 中断影响转发效率，多加内存应该能缓解但是现在太贵了，于是转而想完成 docker 服务和宽带的解耦，考虑现有硬件不变的前提下：将小米 be6500pro 当主路由，n150 主机只装 debian ，同时做旁路网关。

劣势是：

1. 无法实现 ipv6 流量的透明代理，所以我直接关闭了局域网 ipv6 ，另一方面只用 ipv4 也可以使用 realip 模式了
2. 小米主路由固件原生无法指定 dhcp 的下发网关，解锁 ssh 也需要折腾开机自启脚本动态修改/etc/config/network ，试了下哪怕一些需要首次魔法激活的如 quest vr 这种设备，手动改网关也没什么阻碍，故而不对硬路由做任何魔改了
3. iptv 和宽带单线复用无法在小米上直接做到，替代方案是把光猫的 itv 口接小米的 lan 口（和之前 wan.43 加入 br-lan 一个逻辑）
4. 失去了全局 nat1 ，可能会影响 stun 打洞稳定性

优势是：

1. 同样的 sing-box 客户端跑 tun 入站+auto_redirect ，debian13 下的吞吐性能似乎比 openwrt 要好很多
2. debian 直接跑个 sing-box 就是一个旁路网关，配合小米硬路由无需开启 snat 或 masquerade ，直接将其他设备的网关指向 debian 虚拟机就能 work
3. 没手动改网关的设备网络稳定不受 n150 主机影响，完全解耦

另外之前部分 docker 服务，我通过 stun 打洞暴露端口，并用脚本动态修改 cloudflare 的 origin rules 回源，>>>stun 打洞+cloudflare 回源规则，将本地服务放进公网

新方案由于没有 nat1 ，放弃了这个方案，改用 cloudfalre tunnel 的“已发布应用程序路由”进行回源，这个情况下 debian 虚拟机，需要确保每次开机时，cloudflared 先于代理进程启动，以我使用的 sing-box 举例，需在**/usr/lib/systemd/system/sing-box.service**的[service]块中添加 1 行：

ExecStartPre=/bin/bash -c 'until curl -s -f http://127.0.0.1:20241/ready > /dev/null 2>&1; do sleep 1; done'

[elias94]

我咋觉得原方案才是正确的，n150 当主路由，be6500pro 当 ap 。

有一个问题是，网络问题有没有可能是因为路由器的问题，我自己也是 6500pro ，感觉确实会有偶尔断流

我自己的主机 cpu 用的还是 5105 ，配的 ikuai （主路由拨号）+op （旁路由科学）+fnos （轻 nas+跑 docker ），虚拟机平台都给每个虚拟机限定了内存使用量。目前也没遇到 cpu 负载跑满，ikuai 和 op 也从来不会内存负载跑满。fn 偶尔转码的时候会跑满。

[LongLights]

补充：小米路由器的网页端其实直接能改 dhcp 的默认网关到旁路由

[FanDeBiao]

n150 做主路由好点