單元 17 政策路由：規則先選表
學習目標與問題
先讀 07 的單表模型與三個決策、13 的轉送與路由控制、16 的 SNAT 與有狀態防火牆。本單元學 Linux 政策路由：規則依 priority 先選表，最長前綴匹配在所選的表內。完成後應能預測指定來源的規則、表與下一跳，寫出 LAN 與目的例外的順序及回程條件，並區分路由、來源偏好與 SNAT。VPN 伺服器的路由例外見 27，代理分流見 28。
問題：只加一條「來源 2 查表 200」的規則，來源 2 送往同 LAN 的封包為何可能交給 G2？
17.1 從單表到規則
沿用 07 的拓樸。07 的三個決策只查 main 表；政策路由在表內路由之前多一個決策：
| 決策 | 例子 | 不代表什麼 |
|---|---|---|
| 規則選表 | from 來源 2 lookup 200 | 不先比較所有表的前綴長度 |
對未綁定來源的新連線，單靠 from 來源 2 規則，不能期望系統先猜「我要 G2」再選來源 2。需要穩定選出口時，可顯式 bind，或使用目的／mark 等先選表的政策；真實 socket 與系統可能有其他限制，須實際查驗。
17.2 RPDB 規則先選表，LPM 在表內
Linux Routing Policy Database 按 priority 由小至大檢查規則；規則可以依來源、目的、入口或 fwmark 等查表。預設常見順序為 0 查 local、32766 查 main、32767 查 default。下面在其間加入 priority 100；數字 200 是自訂表號，與 priority 不同。本機位址記在 local 表。
ip rule add priority 100 from 198.51.100.10/32 lookup 200
ip route add table 200 192.0.2.0/24 dev eth0 src 192.0.2.10
ip route add table 200 198.51.100.0/24 dev eth0 src 198.51.100.10
ip route add table 200 default via 198.51.100.1 dev eth0 src 198.51.100.10這是隔離 H 的設定摘錄；完整步驟與清除見 L15，不在日常主機直接照貼。查表規則通常在該表找到可用路由後停止；沒有匹配路由或命中 throw 可繼續下一規則，unreachable 等拒絕路由則可產生終止錯誤。main 內更長的前綴不會跨表推翻已成功的 table 200 查找。
完整例題
| 目的／來源 | 命中規則與表 | 下一跳／理由 |
|---|---|---|
| S／未指定 | main | G1，路由偏好來源 1 |
| S／來源 1 | main | G1，來源 1 不匹配 priority 100 |
| S／來源 2 | priority 100→200 | G2，表 200 的預設路由 |
| 198.51.100.55／來源 2 | priority 100→200 | on-link，200 內的 /24 |
| 本機 192.0.2.10／來源 2 | priority 0→local | 本機交付，不送 G2 |
若表 200 只放 default，來源 2 送同 LAN 的 .55 也會命中該 default、交給 G2；main 已有 /24 不能補救。G2 可能再轉回 LAN，也可能拒絕，不能保證一定斷線。可在 200 放直連路由，或讓較早的目的例外查 main，但要檢查 main 的 default 是否使例外涵蓋過廣。
同表相同前綴可再比較 metric 等；跨表依規則順序，不能把「metric 最低」當全系統唯一排序。ECMP、VRF、mark、IPv6 來源選擇另有機制，本例不模擬。
17.3 回程與反向路徑檢查
07 的回程只談可達；加入政策後來源 2 改經 G2，條件變成：G2 須能到 S，S 須能回來源 2，沿路防火牆／NAT 須允許同一連線的回覆（16）。非對稱路由本身不必然錯誤，但可能繞過有狀態防火牆或 NAT。TCP 服務回應常以收到連線的本機位址作來源；UDP 服務若綁萬用位址，回覆來源可能受 socket 與查表影響，需紀錄實際端點。
延伸：反向路徑檢查與 ARP 參數
Linux 的 rp_filter 嚴格模式檢查反向最佳路徑的介面，寬鬆模式檢查來源是否可達；有效值還與 all 及介面設定有關。同一 eth0 上的 G1／G2 通常不會因「閘道不同」而被嚴格模式單獨區分。新增第二張介面時，非對稱路徑才更容易與此檢查衝突。不要將所有回程問題都歸因於 rp_filter。
ARP 行為也受 arp_ignore、arp_announce、arp_filter 等設定影響；多介面同子網尤其要注意主機對其他介面位址的回應。先核對路由、鄰居與封包，再決定是否調整。改 ARP 或反向檢查不是完成隔離的替代品。
17.4 規則順序與例外
例外要排在會先成功的規則之前。例：管理伺服器 203.0.113.81 只能經 G1 到達，其餘來源 2 流量經 G2：
| priority | 規則 | 用意 |
|---|---|---|
| 0 | lookup local | 本機交付 |
| 50 | to 203.0.113.81/32 lookup main | 管理伺服器經 G1 |
| 100 | from 198.51.100.10/32 lookup 200 | 來源 2 經 G2；同 LAN 目的靠表內直連 /24 |
| 32766 | lookup main | 其他流量 |
來源 2 連管理伺服器時以來源 2 經 G1 送出，回程條件同 07。VPN 伺服器例外與隧道遞迴見 27、28。
Linux 的 ip 命令多為執行中設定；重開機、NetworkManager、systemd-networkd 或其他管理程式可覆寫，持久化需配合實際管理工具。macOS／Windows 有不同路由與來源選擇介面，不能直接套用 Linux RPDB 命令。
實驗、習題與檢核
做 L15 階段二：執行 python3 labs/lan_models.py L15，填其餘七案並回答判讀題 1–5；endpoint_exception 一案即本章的管理伺服器例外。判讀題 2、3 的修改用參數 --fix-lan-route 與 --exception-priority 150 重跑，不必改程式。紀錄加上 priority、table 與 trace。延伸 C 在隔離 Linux 命名空間逐次看 route get、neigh 與 ping，仍為選做。本例未作 Linux 實測，預期輸出須與實測紀錄分開。
- 分析：H 另加 priority 90 的
to 203.0.113.0/24 lookup 300，表 300 只有default via 198.51.100.1，main 另有203.0.113.90/32 via 192.0.2.1。來源 1 送往 203.0.113.90 會交給誰？main 的 /32 為何救不回來？提出兩種修正。 - 基本：表 200 加入
throw 203.0.113.0/24後，來源 2 送往 S 會交給誰？改成unreachable 203.0.113.0/24又如何？哪一種會繼續查 main？ - 分析：管理伺服器例外若誤放在 priority 150，未指定來源、來源 1、來源 2 送往 203.0.113.81 各交給哪個閘道？如何逐一測試，特別是來源 2？
檢核：能在同一筆紀錄分別寫來源、規則、表、匹配前綴、下一跳、介面及回程；能說明哪些只是模型。
來源（查閱 2026-10-06）：ip-rule、ip-route、Linux IP sysctl。命令以 Linux／iproute2 語義編寫；本文拓樸與題目為獨立設計。