我有一台 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 ，同时做旁路网关。
劣势是：
- 无法实现 ipv6 流量的透明代理，所以我直接关闭了局域网 ipv6 ，另一方面只用 ipv4 也可以使用 realip 模式了
- 小米主路由固件原生无法指定 dhcp 的下发网关，解锁 ssh 也需要折腾开机自启脚本动态修改/etc/config/network ，试了下哪怕一些需要首次魔法激活的如 quest vr 这种设备，手动改网关也没什么阻碍，故而不对硬路由做任何魔改了
- iptv 和宽带单线复用无法在小米上直接做到，替代方案是把光猫的 itv 口接小米的 lan 口（和之前 wan.43 加入 br-lan 一个逻辑）
- 失去了全局 nat1 ，可能会影响 stun 打洞稳定性
优势是：
- 同样的 sing-box 客户端跑 tun 入站+auto_redirect ，debian13 下的吞吐性能似乎比 openwrt 要好很多
- debian 直接跑个 sing-box 就是一个旁路网关，配合小米硬路由无需开启 snat 或 masquerade ，直接将其他设备的网关指向 debian 虚拟机就能 work
- 没手动改网关的设备网络稳定不受 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'
Select Language