家庭开源网关 03｜OpenWrt 系统选型：代理、DNS、VPN 与 PBR

家庭开源网关系列 · 第 3/8 篇

家庭网关的软件问题经常被简化成“装哪个固件、装哪个插件”。真正决定稳定性的却是另一件事：谁修改 DNS，谁接管 TUN/TPROXY，谁写 nftables 规则，谁决定流量最终走 WAN、代理还是 VPN。

系统和组件都可以更换，但同一条数据路径不应被多套管理器同时控制。

OpenWrt、ImmortalWrt 与 iStoreOS 的定位

OpenWrt：上游基线

OpenWrt 面向嵌入式网络设备，提供可写文件系统、包管理、LuCI 和完整 Linux 网络栈。它的优势是上游文档、设备数据库、标准包生态和长期可维护性。部分中国用户常用的代理插件、镜像源或特定硬件补丁不会默认集成，需要自行核对。

家庭主网关应优先使用正式稳定版。Snapshot 包含最新驱动与改动，但更新节奏快，已安装内核与在线包仓库可能发生 ABI 错配。自编译可以预装软件和初始化配置，却意味着以后要持续维护构建参数与升级路径。

ImmortalWrt：本地化 OpenWrt 分支

ImmortalWrt 官方仓库将项目描述为 OpenWrt 的分支，增加了更多软件包、设备支持、默认优化和面向中国大陆用户的本地化修改。

对于 ARM64 设备、中文环境和代理生态，它通常更省配置时间；但“同一个 SoC 可以运行”不等于精确型号存在稳定镜像，仍然要在对应 Firmware Selector 中确认设备与版本。

iStoreOS：路由与轻 NAS 的图形化组合

iStoreOS 官方仓库把它定位为入门级路由和入门级 NAS 系统，并基于 OpenWrt 扩展应用管理。它适合希望通过界面部署存储和轻服务的用户。

需要注意，当前活跃分支、内核、防火墙后端和插件兼容性都会变化。选择 iStoreOS 时，应以官方支持平台与当前发布说明为准，不要只依据旧教程中的界面和插件列表。

厂商固件与 x86 系统

FriendlyWrt 等厂商固件通常最先支持自家开发板的启动、eMMC、网口和恢复工具，适合新硬件验证与救砖。长期包生态和内核节奏则更依赖厂商。

x86 还可以选择 OPNsense、pfSense、VyOS 或通用 Linux。它们更接近企业防火墙或服务器，但功耗、配置和维护成本也更高。第一次构建家庭网关时，OpenWrt 系列通常更容易形成可恢复的最小系统。

把这些选择放在同一张表里，会比比较界面截图更有用：

系统名称并不能替代版本信息。同一设备的稳定版、Snapshot、厂商分支和第三方整合镜像可能使用不同内核、分区布局与包仓库。部署记录中应写清楚完整镜像名称、版本、目标架构、文件系统和下载来源，而不只写“装了 OpenWrt”。

系统选择先看这五个问题

不要先根据截图选择系统。先确认硬件支持、升级方式和最小恢复路径，再看界面与插件。

稳定版、Snapshot 和自编译如何取舍

稳定版适合作为家庭主网关基线。它不保证没有缺陷，但包仓库、内核 ABI 和升级路径相对固定，出问题时也更容易找到同版本资料。

Snapshot 适合稳定版尚未支持的新硬件，或者确实需要尚未发布的驱动与功能。它的代价是持续滚动：一段时间后再安装内核相关包，可能遇到仓库包与设备当前内核不匹配。使用 Snapshot 时，应该把所需包预装进镜像或保存可复现构建配置，并准备完整重刷方案。

自编译适合需要固定软件集合、初始化配置或补丁的用户。它带来的并非一次性的编译工作，而是一条长期维护链：源码分支、feeds、配置文件、补丁、构建环境和升级验证都要保存。没有维护这条链的意愿时，少装几个插件的官方稳定镜像往往更可靠。

代理组件只能有一个主控制器

透明代理通常同时涉及：

• DNS 解析与缓存；
• TUN 或 TPROXY 流量接管；
• nftables/iptables 规则；
• 连接跟踪和路由标记；
• 局域网、上游网关和代理服务器地址排除；
• IPv4 与 IPv6 的一致策略。

同时运行多套透明代理插件，最容易出现的不是“性能变慢”，而是规则互相覆盖、DNS 循环、回程错位和升级后依赖冲突。

HomeProxy / sing-box

HomeProxy由 ImmortalWrt 组织维护，官方描述是面向 ARM64/AMD64、由 sing-box 驱动的现代代理平台。它适合希望使用单一核心、并让代理与 ImmortalWrt/firewall4 生态保持一致的用户。

OpenClash

OpenClash 官方仓库将其定义为运行在 OpenWrt 上的 Mihomo/Clash 客户端，提供基于规则的策略代理。它的规则与 UI 生态丰富，但依赖 dnsmasq-full、TUN、TProxy 和防火墙模块，升级时需要同步检查系统分支与依赖。

PassWall / PassWall2

PassWall与PassWall2提供另一类多核心、节点与分流管理方式。它们同样会介入 DNS 和防火墙，因此不应与另一套透明代理管理器同时接管全局流量。

这三类方案不存在脱离硬件、规则数量、节点协议和系统版本的绝对性能排序。长期运行时，依赖可解释、升级可回退、故障时能恢复直连，比功能数量更重要。

选择代理管理器时，可以把问题收敛为四项：目标系统是否提供匹配的软件包；需要的节点协议和规则模式是否支持；DNS 与 IPv6 路径能否解释；升级失败时能否一键停用并恢复直连。不要因为某套 UI 的开关更多，就同时保留另一套作为“备用”并让两者加载规则。真正的备用方案应是可恢复的配置或系统镜像，而不是第二个正在接管数据面的插件。

DNS 链路保持单向

推荐的最小链路是：

终端
  → DHCP 下发的主网关 DNS
  → dnsmasq / 主 DNS 入口
  → 分流解析器或一个加密上游

设计时保留四条约束：

1. 客户端只认一个稳定 DNS 入口。
2. 局域网名称解析在代理停止时仍然可用。
3. 域名分流要说明解析结果怎样进入路由规则。
4. IPv6 AAAA 记录不能绕过只处理 IPv4 的代理策略。

没有明确数据流时，不要堆叠 dnsmasq → AdGuard Home → MosDNS → SmartDNS → 代理 DNS。每多一层都会增加缓存不一致、循环和故障定位成本。

DNS 设计还需要回答三个边界问题。

第一，局域网名称由谁维护。NAS、打印机和 Home Assistant 的本地域名最好仍由主网关或明确的内部权威入口解析，不能因为代理进程停止就全部失效。

第二，域名分流怎样影响后续路由。有些方案通过解析结果生成地址集合，再由 nftables 或 PBR 选择出口；有些方案使用 Fake-IP，把域名语义保留给代理核心。两条路线都可以工作，但混用后很难判断一条连接为什么进入某个出口。

第三，失败时怎样回退。加密上游不可达、代理节点离线或过滤服务崩溃时，是自动使用直连 DNS，还是按安全策略拒绝解析？家庭环境通常需要明确的基础回退，避免一个附加服务让所有设备表现为“断网”。

可以用四组查询验证链路：局域网主机名、普通国内域名、需要特定策略的域名以及仅返回或优先返回 IPv6 的域名。每组都记录查询由谁回答、得到什么地址、连接最终走哪个出口。

VPN 与 PBR 解决不同问题

WireGuard 适合让外部手机或笔记本安全进入家庭 LAN，也可以作为网关的远端出口。OpenWrt 官方 WireGuard Server 文档给出了服务端、客户端与防火墙配置路径。

自建 WireGuard 服务端需要外部设备能够找到家庭端点。拥有公网 IPv4、可用公网 IPv6 或可以在上游做端口转发时，可以直接建立入站隧道；处于运营商 CGNAT 且没有可达 IPv6 时，则需要中继、组网服务或一台公网节点。Tailscale、ZeroTier 等方案把节点发现和穿透封装起来，适合不想手工维护公网入口的家庭，但仍要明确账号、控制面、访问规则和故障依赖。

远程接入隧道建立后，不应默认允许访问所有 VLAN。给 VPN 单独建立防火墙区域，只开放管理网段、NAS 或 Home Assistant 等确实需要的服务，既能减少风险，也便于从日志判断远程访问发生了什么。

PBR 则根据策略选择不同路由表。OpenWrt PBR 文档列出的匹配条件包括接口、源/目的地址和防火墙标记。它适合实现：

• 指定设备走 VPN，其余设备走 WAN；
• 指定网段或端口进入另一出口；
• VPN 服务端与客户端同时运行；
• 在一个物理网络内按设备分流。

如果目标只是“部分设备使用不同出口”，PBR 比拆成两个 Wi-Fi 更精确；如果还要限制设备互访，则应结合 VLAN 和防火墙，而不是把分流误当成隔离。

PBR 上线前要准备绕过清单。局域网网段、上游光猫管理地址、DNS 服务、代理或 VPN 服务器自身地址，以及用于健康检查的必要目标，都不应被错误送回隧道形成环路。规则应从单一测试设备开始，依次验证直连目标、策略目标、DNS、IPv4、IPv6 和隧道断开后的回退行为。

一个可审计的策略记录可以很简单：

当一条规则无法在这四列中写清楚时，先不要把它扩展到全家设备。

推荐的启用顺序

基础路由
  → 稳定 DNS
  → 选择一套代理管理器
  → 单设备验证
  → 扩大到全网
  → 加入 IPv6 策略
  → 配置 VPN / PBR

每完成一个阶段就备份。某一步出现异常时，能够退回上一条已验证路径，比同时修改五个组件更快。

软件栈的最小运行档案

正式接管家庭网络后，保存以下信息：系统版本与镜像来源、已安装包清单、主代理管理器、DNS 调用链、生成规则的组件、VPN 接口与密钥备份位置、PBR 规则说明，以及停用所有附加组件后恢复直连的方法。

每次升级只改变一个层次。先验证基础 WAN/LAN、DHCP 和 DNS，再恢复代理，随后恢复 VPN/PBR，最后才启用广告过滤、统计和其他增强功能。这样即使插件兼容性发生变化，也能知道是哪一层让数据路径偏离预期。

这份档案还应标明每个组件的停止方法和依赖关系。维护者即使隔了半年，也能在不删除配置的前提下停用附加功能，回到可验证的基础网络。

下一篇将回到硬件层，从网口、总线和实际负载比较 ARM 开发板与 x86 网关。

参考资料

• OpenWrt 官方项目与文档
• ImmortalWrt 官方仓库
• iStoreOS 官方仓库
• OpenWrt：Netfilter Management
• OpenWrt：Routing rules