开启 3 天免费试用
注册即可免费体验全部高级功能。
*仅限新用户；每位用户只能获得一次试用。
OpenWrt 策略路由：按设备分流与 VPN 验证
Ryan Foster
2026年10月11日· 7 分钟阅读
OpenWrt 策略路由可以让一台 LAN 设备经过获授权的隧道，另一台继续走 WAN。普通默认路由应保留在 WAN，设备身份必须稳定；DNS、IPv6 和隧道失效行为要分别验证，不能用一次 IPv4 网页请求成功替代验收。
关键要点
- 设备身份和策略顺序决定哪些请求命中。
- 路由器自身请求不能代表 LAN 客户端请求。
- 严格执行只覆盖匹配策略，不代表全部流量防泄漏。
- 路由器转发的 DNS 会成为独立的本机上游流量。
- 保留管理例外，只撤销本次练习的改动。
OpenWrt 策略路由适用于哪些情况？
本文适用于 OpenWrt 25.12 稳定系列、fw4/nftables 和 pbr 1.2.2，采用常规动态路由表模式。官方发行源提供 1.2.2；安装前仍须确认自己的架构和固件所提供的包。维护者把初步支持的 netifd 集成单独说明，本文不启用该集成或多 WAN 集成。［1］［2］
步骤依据官方文档和包配置编写，未进行完整设备端到端实测。下文是读者应执行的验收方法，不是已观察到的结果。先用自建维护责任清单确定恢复和维护负责人。
如果只有一个应用需要改路径，先比较应用代理和整机路由。按设备策略会增加配置责任和失败模式；它不会创建隧道，也不会改变商业应用设置实际支持的功能。
步骤 1：固定两台设备身份，保留独立管理入口
设备 A 走隧道，设备 B 走 WAN。在 DHCP 中保留它们原有的 IPv4 地址，例如 192.168.8.10 和 192.168.8.20，核对当前租约。记录可能改变身份的随机 MAC 和多网卡。第三台有线管理电脑不纳入这两条策略。
将 /etc/config/pbr、/etc/config/network、/etc/config/dhcp 和 /etc/config/firewall 私密备份到路由器之外。原先没有安装 pbr 就记录“未安装”，不要编造原始配置。保存服务原有启用状态和既有策略，避免恢复时停掉别人的路由。
先验证 WireGuard 客户端接口及返程。示例使用已正常工作的 wg_test。测试 LAN 必须获准向该接口转发，服务端也须允许转发流量，并明确选择 IPv4 地址转换或返程路由。
访问互联网时，对端 AllowedIPs 可能需要 0.0.0.0/0，但应关闭 Route Allowed IPs，避免安装争抢全局流量的默认路由。仅替换或移除自己早先加入的测试路由。可结合 AllowedIPs 与系统路由的关系理解这两项不同职责。保留通向隧道端点的 WAN 路径和现有 LAN 直连路由。［3］
步骤 2：检查发行包并选择受支持后端
仅在获授权路由器上，通过其已配置的可信 25.12 软件源安装。确认提供的 pbr 为 1.2.2，依赖能与本机固件匹配；不匹配就停止，不强装旧包，也不在本次练习中更换固件。［1］［2］
apk update
apk list pbr
apk add pbr luci-app-pbr
apk list --installed pbr
启用之前查看 Services → PBR 及其状态，确认 fw4/nftables、识别到的 WAN 和 wg_test。若已有 netifd 扩展、mwan4 或其他路由管理器，停止此路径；迁移现有架构不属于这个两设备示例。
这里只按来源地址匹配，不匹配域名，选择 resolver_set: none，无需仅为源 IP 策略替换 dnsmasq。明确保留 strict_enforcement: 1；若用计数器观察，启用 nft_rule_counter: 1 并记录原值。发行配置默认未启用计数器，IPv6 支持也须主动配置后才启用。［2］［4］
步骤 3：按顺序建立 OpenWrt 按设备 VPN 策略
通过 LuCI 或在现有 pbr 配置中添加以下片段。它们不是整个文件的替代品。使用未占用的段名及实际逻辑接口名，保留已有授权策略，检查它们是否与本次范围重叠。［2］
config policy 'sh26_local'
option name 'SH26 local management destinations'
option src_addr '192.168.8.10 192.168.8.20'
option dest_addr '192.168.8.0/24'
option interface 'ignore'
config policy 'sh26_tunnel'
option name 'SH26 device A'
option src_addr '192.168.8.10'
option interface 'wg_test'
config policy 'sh26_wan'
option name 'SH26 device B'
option src_addr '192.168.8.20'
option interface 'wan'
本地例外放在设备全流量策略上方。配置中越靠上的策略优先级越高；ignore 让匹配请求回到普通路由，并不赋予防火墙访问权限。其他管理网段只有实际存在且获授权才加入。过宽的私网例外可能把原本应入隧道的远端私网流量送到隧道外。［2］
在 LuCI 中启用 pbr 配置并启动或重启服务，立即检查状态和报错。缺少接口或网关时，不能因为配置保存成功就接受结果。设备数据包根本不经过本路由器，来源策略就无法改变它的路径。
如何区分 pbr DNS 路由和浏览器流量？
先明确设计：客户端直接向获准解析器发送 DNS，其包按设备策略路由；或者客户端查询路由器，再由路由器单独请求上游。第二种设计不会自动继承设备 A 的隧道策略。记录解析器地址及其请求的实际出口路径。
可选的 pbr DNS 策略字段为 name、src_addr 和 dest_dns，目标可以是解析器，也可以是配置了 DNS 的接口。不要填写虚构地址。这类拦截针对匹配的 DNS 请求，不覆盖所有加密 DNS 应用，而且可能绕过 dnsmasq 的域名集合处理。本次最初的来源 IP 练习不含域名策略。［2］
分别从 A、B 查询一个自己控制的新名称，再独立观察路由器的解析行为。记录浏览器 DoH、系统私有 DNS 和终端原有 VPN；不要关闭无关软件来制造看起来干净的结果。若续租或重启后设置丢失，先按路由器 DNS 持久化检查排查，再增加策略。
IPv6 和隧道失效会怎样？
IPv4 来源策略不能证明 IPv6 也受覆盖。IPv6 隐私地址可以独立于 DHCPv4 保留地址变化。双栈验收需要启用 pbr IPv6 支持、建立受支持的 IPv6 隧道及返程，并配置对应 IPv6 身份或合适且受支持的设备选择方式。检查 A、B 正在使用的所有地址，不要假定一个固定地址覆盖全部请求。［2］［4］
该分支不具备条件时，只能使用本来就仅有 IPv4 的测试网段，或停止把它描述为整机 VPN。不要关闭共享网络的 IPv6。若约定要求设备全部流量入隧道，意外走 WAN 的 IPv6 就是失败；只有预先明确选择的例外才是有意行为。
严格执行应在目标接口 down 时让匹配流量不可达。它不能证明“接口仍 up、远端对等端已不响应”会被正确识别，也不覆盖未匹配 IPv6、路由器 DNS 或服务停止期间。将接口 down和接口保持 up 但远端不响应作为两种不同故障分别测试。［2］
| 检查方法 | 预期现象 | 失败处理 |
|---|---|---|
| A、B 分别建立新的公网请求 | A 使用授权隧道出口，B 使用 WAN | 检查身份、顺序、标记及路由表 |
| 查看 pbr 状态和已启用 nft 计数器 | 对应设备的匹配策略计数变化 | 确认包经过本机，不只看服务状态 |
| 对比客户端直发 DNS 和路由器发起 DNS | 各自符合记录的设计 | 撤销解析器改动，独立检查该流量 |
| 两台设备分别重复 IPv6 请求 | 结果符合明确的 IPv6 决策 | 发现非预期 WAN 绕行即停止验收 |
仅关闭 wg_test | 严格执行下 A 的匹配请求失败，B 和管理正常 | 检查漏匹配流量及冲突策略 |
| 恢复隧道，再执行获准重启 | 策略和身份保留，新请求重新命中 | 恢复基线并检查保存项 |
从每台设备对比可见公网出口，同时保留策略及解析器证据。两个路径可能共享公网 IP，相同地址本身不能证明规则成功或失败。既有连接、软硬件流量卸载和缓存会影响观察；增加改动之前先检查新连接。
步骤 4：恢复原有策略并验证管理访问
撤销可选 DNS 策略和本次三个 sh26_ 策略，恢复保存的 pbr 选项及服务状态，通过原服务管理方式重新加载。若 pbr 仅为本次新装，先停止并禁用再移除；若它原先承载其他规则，保留服务并加载保留下来的配置。
恢复专为此次改变的 WireGuard 路由选项、地址保留、解析器和测试防火墙权限。不要清空 nftables、删除全部策略表，也不要用旧整文件覆盖后续改动。检查 A、B 的新 WAN 请求、正常 DNS 和新建的有线管理会话。
维护者说明，服务处理过程中遭到中断可能让 LAN 到 WAN 转发保持禁用。service pbr enable_forward 是有条件的恢复动作，不是通用修复命令：先确认确属这种故障，恢复预期的安全防火墙和策略基线，再确认是否授权 WAN 回落。否则应停止并本地恢复，不能悄悄放开路径。［2］
总结
- 匹配稳定的设备身份，保留范围明确的管理例外。
- 让 pbr 管理动态表，WAN 继续作为普通默认路径。
- 分别验证 DNS、IPv6 和两类隧道故障。
- 只回退本次修改的策略和选项。
常见问题
能否在路由器上发请求验证设备策略？
不能。本机发起请求的来源和处理路径不同。应在实际 LAN 设备上产生新流量，并与策略证据交叉核对。
第一条还是最后一条策略优先？
维护者文档规定靠上的策略优先。将范围明确的管理例外放在广泛设备策略上方，并检查更早的重叠规则。
来源 IP 策略需要 dnsmasq-full 吗？
本练习不用域名集合解析，选择 resolver_set: none。域名策略有独立解析器要求；不要仅为匹配设备地址替换正常运行的 DNS 服务。
严格执行等于完整断网保护吗？
它受匹配策略和目标接口状态约束。未匹配地址族、路由器 DNS、停止的服务及看似 up 但无响应的对端都须另外验收。
A 重新连 Wi-Fi 后为何换了路径？
当前 IP、随机 MAC 或网卡可能改变。修改路由表之前，先把当前租约及 IPv6 地址与策略选择条件比较。
可以有意允许 WAN 回落吗？
可以，但负责人必须明确接受并测试这种故障行为。记录允许哪些设备、地址族及 DNS 回落，不要把这种设计称为严格阻断。
恢复时应清空所有 nftables 规则吗？
不应。这样会删除其他服务的保护，也无法恢复配置责任边界。移除本次配置段，恢复保存的选项，并重新检查管理连接。
来源:
- OpenWrt 25.12 — pbr release package definition — https://raw.githubusercontent.com/openwrt/packages/openwrt-25.12/net/pbr/Makefile
- MOSSDeF — pbr 1.2.2 documentation — https://docs.mossdef.org/pbr/1.2.2/
- OpenWrt — Policy-based routing — https://openwrt.org/docs/guide-user/network/routing/pbr
- OpenWrt 25.12 — pbr default configuration — https://raw.githubusercontent.com/openwrt/packages/openwrt-25.12/net/pbr/files/etc/config/pbr
Sources checked 2026 年 10 月 11 日。
延伸阅读:
