開啟 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 路由及瀏覽器流量？
先選定設計：客戶端直接查詢獲准解析器，封包按裝置策略走；或客戶端查詢路由器，再由路由器獨立查詢上游。後者不會自動繼承 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。若約定所有流量必須入隧道，非預期的 IPv6 WAN 繞行就是失敗；只有事先明確選定的例外才屬有意安排。
嚴格執行應在目標介面 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 日。
延伸閱讀:
