單元 28 流量接管、分流、DNS 與軟路由整合
學習目標與問題
整合 22 至 27。你應能解釋系統代理、TUN/TAP 和透明代理的差異，畫出 DNS／IPv4／IPv6／UDP 路徑，並找出策略缺口。協定只解決通道的一部分，「代理已連線」不能替完整路徑作證。
本章 §28.2 與 §28.4 把 17 的政策路由接進代理分流；LAN 探索、跨 VLAN 與印表機的資料路徑回讀 15 與 L16，VPN 開啟後的本地探索回讀 §27.6。
28.1 應用怎樣進入通道
系統代理是 OS／應用約定，配合 HTTP／SOCKS 端點；不遵守的應用可以直接建立其他 socket。PAC 可依請求選擇，但支援與規則依實作。TUN 讓程式收發三層 IP 封包，TAP 收發二層訊框；介面本身不提供加密、遠端 peer 或可靠傳輸。使用者空間 stack 或路由程式還需處理封包和通道。
透明代理以 redirect／TPROXY／policy routing 等機制讓未顯式設定的流量進代理；必須保留／取得原始目的資訊，處理回程、loop 及 UDP 狀態。具體實作和系統權限差異很大，不能把 Linux 命令套進 macOS 或 Windows。軟路由是一種設備／部署角色，可組合路由、防火牆、DHCP、DNS、代理/VPN，不是新的加密協定。
28.2 分流先定義意圖
目標可以是「企業私網經 VPN」「某類域名經代理」「所有應用資料經指定出口」。規則要寫輸入、優先序、預設值及不可獲得域名時怎麼處理。域名規則常需要顯式代理請求、DNS 關聯、Fake IP 或 sniffing 提供資訊；SNI 加密、快取、直接 IP 和連線重用會限制觀察。
Fake IP 用保留的合成位址與對映表把名稱關聯到流量，代理再還原真實目的。它不是公開 DNS 位址，也不是加密機制；位址池衝突、對映壽命、繞過 DNS 的應用和快取可能影響正確性。實作選擇的位址池和排除規則須查具體版本。
OS 政策路由看到的是該查表階段的 IP 與標記等資訊。軟路由還要區分「LAN 客戶端轉送流量」與「代理程式新建的上游 socket」：前者的來源可能是客戶端 IP，後者是代理主機 IP。只寫 from 客戶端規則，不保證代理上游仍走同一路徑。
28.3 DNS 是獨立路徑
應用可能用系統 DNS，也可能自己做 DoH/DoT 或直接 IP。DoT 把 DNS 放 TLS，DoH 把 DNS 放 HTTPS，DoQ 用 QUIC；加密 DNS 不自動通過 VPN/代理，也不讓 resolver 看不見查詢。代理伺服器的名稱需要 bootstrap，若所有解析都依賴尚未建立的代理，可能產生依賴循環。
先畫：應用→本地 stub→遞迴 resolver→權威；再標每個請求的出口。比較實際與政策，才能判斷是否有不預期的 DNS 路徑。DNSSEC 驗證與通道加密另行標示，不將「防洩漏」等同解析資料真實。
28.4 完整整合例題
政策：本機網站流量都走 P，LAN 印表機直連，P 的外層 endpoint 走實體出口。實際規則只有 IPv4 TCP 被接管；瀏覽器使用 AAAA 與 QUIC 時，IPv6 UDP 可能走原出口。修正要看接管覆蓋、IPv6 路由、UDP 轉送及 fallback 政策；僅把 DNS 改成 P 提供的 resolver 無法自動修補資料路由。
規則順序：保留 local 交付；目的 LAN 直連；VPN／代理 endpoint 走 underlay；剩餘流量依來源或 mark 入隧道。若 endpoint 例外把某 IP 留在 underlay，對同 IP 其他服務也可能受影響，應說明取捨。
| 流量 | 預期 | 必須核對 |
|---|---|---|
| 目標 A/TCP | P | 入口、目的規則、出口 |
| 目標 AAAA/TCP | P | IPv6 接管與 P 的 IPv6 出口能力 |
| 目標 UDP/443 | P 或明確拒絕並 fallback | UDP 入口、relay 能力、應用行為 |
| DNS／DoH | 指定 resolver 路徑 | 應用繞過、bootstrap 與出站路由 |
| LAN 印表機 | 本地 | 直連例外優先、對應網段 |
| P endpoint | underlay | 免進入自身隧道、防 loop |
本題位址／行為是模型。實際驗證需本機入口、實體出口和 P 端日誌等證據；不能僅靠網頁顯示一個公網 IP 證明所有協定全部覆蓋。
軟路由還要檢查 RA 來源、預設路由及 SLAAC。若 LAN 由另一 IPv6 路由器取得預設路由，僅攔截 IPv4 的設備可能被繞過；需在自主管理的拓樸控制 RA 與雙協定接管，而非任意停用所有 ICMPv6。Fake IP 對映重啟後遺失、客戶端仍有舊合成位址快取，是另一可檢查故障。
28.5 出口失敗的分類
出口失敗應區分：規則未匹配、proxy 域名解析失敗、握手認證失敗、目標解析失敗、目標連線失敗、MTU 和資料階段。各層日誌依 §22.5 的方法對照：先以各自的連線 ID 整理，再用時間與端點找出前後相接的連線，注意時鐘誤差。鏈式代理每多一跳，就多一組這些失敗點，要逐段判斷。不要同時修改所有規則來「試試看」。
實驗、習題與檢核
本單元只用一張政策表，就是 L14 C 的全流量政策表。前面實驗的結論只回讀，填進對應的列，不重做、不另交：
| 政策表的列 | 回讀的結論 | 出處 |
|---|---|---|
| DNS | 送域名時由 P 解析；先在 C 解析再送 IP 時，C 的解析器看得到名稱 | L09（22 的兩張解析圖） |
| P endpoint | endpoint 留在 underlay，外層封包才不會遞迴進自己的隧道 | L10 主體（27） |
| LAN 與 P endpoint 的規則順序 | 目的例外排在來源或 mark 規則之前 | L15（17） |
| 代理上游 socket | 本機新建的 socket 依自己的來源查表，不沿用 LAN 客戶端的來源規則 | 本章 §28.2；來源查表原理回讀 07、17／L15 |
| LAN 探索與跨 VLAN | 本例的 mDNS 探索只在本鏈路；跨 VLAN 的資料連線是單播，另走路由 | L16（06、15） |
其餘各列（RA 來源與 IPv6 預設路由、IPv4／IPv6 TCP、UDP、應用 DoH、直接 IP）依 28.1 至 28.4 填寫。本單元要交的只有兩項：L14 新增 C 與 D 的完稿，依 D 的規準一次總評；L12 新增案例 D，離線完成，再把五個案例的案例表一次提交。
- 基本：TUN 是否保證加密與全流量覆蓋？
- 分析：系統 proxy 為何可能漏掉應用 UDP？
- 基本：為什麼加密 DNS 不自動表示經 VPN 傳送？
- 分析：單次公網 IP 測試不能驗證哪些流量？
- 延伸：代理上游 socket 的來源與客戶端來源不同，如何用擷取證明兩次查表的差異？
檢核：能分別檢查接管、規則、DNS、通道及出口，而且同時考慮 IPv4/IPv6 與 TCP/UDP。來源：Linux TUN/TAP 文件、Linux TPROXY 文件、RFC 7858（DoT）、RFC 8484（DoH）、RFC 9250（DoQ）、Xray FakeDNS 設定。