跳转至

基于 RouterOS、OpenWrt、SmartDNS 与 FRP 的家庭网络架构

这篇文章记录一个围绕 MikroTik RouterOS、OpenWrt 旁路由、SmartDNS、Tailscale 和 FRP 搭建的家庭网络架构。它不是一份可以直接复制粘贴的配置教程，更关注“职责归属”：哪个设备应该负责路由、DNS、代理、IPv6、公网服务和恢复。

设计目标

当家庭网络不再只是“一台路由器 + 几个终端”时，最重要的是让结构仍然能被理解：

  • RouterOS 保持主路由和策略 owner。
  • OpenWrt 保持代理和 Tailscale owner。
  • SmartDNS 为 LAN 提供稳定的 DNS 入口。
  • RouterOS 上的容器降低对旁路由的硬耦合。
  • FRP 通过 VPS 节点发布少量被选中的内网服务。
  • 每一次变更都必须有回退路径。

拓扑

Internet / IPv6 PD / FRP VPS
        |
        v
MikroTik RouterOS
主路由 / DHCP / DNS 入口 / IPv6 owner / 防火墙 / QoS / 容器
        |
        +-- SmartDNS container
        |   LAN DNS 主服务
        |
        +-- Xray container
        |   为 SmartDNS 的部分上游提供代理后端
        |
        +-- FRPC container
        |   连接远端 frps，并发布被选中的内网服务
        |
        +-- OpenWrt 旁路由
        |   Passwall、细分流、Tailscale subnet router 和 exit node
        |
        +-- NAS
            存储、应用、下载任务，以及被允许的 IPv6 公网服务

职责模型

最关键的决策是避免职责重叠。当两台设备都认为自己拥有同一个功能时，排障会变慢，恢复也会变脆。

服务面 Owner 原因
LAN 网关 RouterOS 它是物理边界路由器，适合承担 DHCP、防火墙、IPv6 RA 和 QoS。
IPv4 粗分流 RouterOS address-list 与 mangle counter 在主路由上更容易审计。
代理细分流 OpenWrt Passwall 更适合处理应用级和域名级代理策略。
DNS 入口 RouterOS 上的 SmartDNS LAN 客户端只需要面对一个稳定 DNS 入口。
DNS 代理后端 RouterOS Xray 优先，OpenWrt fallback 降低 DNS 解析对旁路由的依赖。
远程管理 Tailscale 优先 管理路径不应该依赖被它修复的公网服务隧道。
公网服务隧道 FRP 用于发布 NAT 或动态地址背后的少量 HTTP/HTTPS 服务。

流量路径

普通 LAN 流量

大多数 LAN 流量直接经过 RouterOS。RouterOS 负责 NAT、防火墙、IPv6 和 QoS，这样默认路径足够简单，也足够可预期。

需要代理的设备

需要代理的终端被放入 proxy-device 列表。RouterOS 先做粗分流：国内或明确直连的目标保持直连，非直连 IPv4 流量可以送到 OpenWrt 旁路由。OpenWrt 再通过 Passwall 做细粒度策略判断。

这样主路由回答“这类流量先去哪里”，OpenWrt 回答“这条流量具体匹配哪个代理规则”。

DNS

LAN 客户端使用 SmartDNS 作为主 DNS 服务。SmartDNS 通过 domain-set 和上游组区分直连、国内、海外和特殊域名。

一个重要改进是让 RouterOS 自己提供 SmartDNS 可用的代理后端。这样旁路由离线时，DNS 仍然可以清晰地 fallback，而不是让每一次 DNS 决策都依赖 OpenWrt。

IPv6

RouterOS 负责 IPv6 前缀、LAN 通告、DHCPv6 行为和防火墙转发。IPv6 公网服务应该严格最小化。对于 NAS 这样的主机，固定 IPv6 token 比单纯依赖 DDNS 更容易推理。

FRP 公网服务

FRPC 作为 RouterOS 容器运行，连接 VPS 上的 frps。只有被选中的服务会暴露到公网。生产 FRPC 先通过 canary 验证，再正式替换，同时保留旧容器镜像作为短期回退点。

可观测性

接口流量图很有帮助，但它不是分流正确性的证明。例如旁路由的 TX/RX 曲线接近对称，并不能直接证明本应直连的流量被代理了。

更可靠的证据来自成对 counter：

  • 测试窗口前后的 RouterOS mangle counter。
  • 同一个窗口内的 OpenWrt nftables 或 Passwall counter。
  • SmartDNS 查询样本，用于判断 DNS 上游归因。
  • 测试 subnet route 或 exit node 时的 Tailscale 接口 counter。

有用的习惯是一次只测试一种流量：国内 IPv4、海外 IPv4、IPv6 直连、DNS 代理上游、Tailscale，以及高连接数 P2P 流量。

回退策略

每个阶段开始前都应该先准备 fallback：

  • 保持 LAN 或 Tailscale 管理路径可用。
  • 一次只改一台设备、一个功能面。
  • RouterOS 高风险变更前先导出配置。
  • OpenWrt 网络类变更前保留 sysupgrade 备份。
  • 正式替换容器前先做 canary。
  • 只保留最新的有效备份，以及失败或回退证据。

这不只是“文件整洁”。恢复面越小，网络越不吓人。

阶段依赖

这套架构是分阶段收敛出来的：

盘点与文档
    -> 管理安全
    -> 维护与恢复
        -> IPv6 公网服务边界
            -> DNS、DDNS 与自动化
                -> 代理、QoS、容器与观测
                    -> 路由与分流
                        -> 旁路绕行观测

管理安全 + 恢复能力 + 容器健康
    -> FRP 边缘隧道升级

这个顺序很重要。很容易一上来就想改代理规则或公网隧道，但真正让后续变更安全的是那些安静的基础层。

经验总结

  • 主路由应该拥有默认路径。
  • 旁路由应该拥有代理智能，而不是整个网络。
  • DNS 需要独立的 fallback 设计。
  • IPv6 公网服务应该用严格 allowlist 思维管理。
  • 远程管理路径不应该依赖公网服务隧道。
  • 配置文档是系统的一部分，不是事后补充。

最终结果仍然是一个会继续演进的家庭网络实验室，但它不再像一堆临时修补。它有层次、有 owner，也有明确的回退点。