第九天講完黑名單 EDL 之後留下一個問題：EDL 執行點吃「放行」決策，nftables 與 CrowdSec 執行點卻不吃，為什麼？要回答它，得先把「白名單」這個字拆開。網管工程師心裡的白名單是一份 IP 清單，命中就免檢查、永久有效、優先於一切。這套架構裡符合這個定義的只有兩處，其餘的「白名單」各自在回答不同的問題。把問題分清楚，那個不對稱就不是例外，而是必然。

先講結論。這套架構裡的「白名單」在回答四個不同的問題：誰能連進來（存取管制）、誰永遠不會被封（免封）、誰說的來源 IP 算數（信任）、對某個來源明確放行（放行決策）。前三種是安裝或管理時設定的固定清單；第四種是案件流程的輸出，帶 TTL，而且只落地到 EDL。它只落 EDL 不是漏做，是因為「放行」的意義是壓過其他封鎖來源，而防禦節點自己只有一個封鎖來源，沒有東西需要被壓過。

一、先拆掉這個字：IP 清單視角漏掉了什麼

用 IP 清單的視角看白名單，只有一個維度：IP 在不在名單裡。但一份清單真正的行為由四個問題決定，而這四個問題在不同的清單上答案完全不同：

總覽第三節已列出八個放行點並標了類型。本篇不重列那張表，而是把其中「以 IP 為單位」的六個依上面四個問題重新分組，再回答不對稱的成因。

二、四種語意各落在鏈上哪裡

A　存取管制：誰能連進來

三處都是同一種東西：一個埠或一個帳號只接受名單內的來源。主機 B 上兩處由同一份 ADMIN_IPS 產生（nftables 的 ingest_guard_、mgmt_guard_、ssh_guard_input 各 chain，加上 ClickHouse 帳號的 networks）；主機 A 上的平台端 EDL 端點 /edl//blocklist.txt 用 OD_EDL_ALLOWED_IPS 限來源。這是最接近網管直覺的白名單，但它與安全決策無關：命中只代表 TCP 連得上，之後該過的檢查一樣過。第 6 篇說設備 IP 不在 ADMIN_IPS 內抓 EDL 會逾時，就是這一類。

B　免封：誰永遠不會被封

方向與 A 相反。A 管「誰能進」，B 管「誰不能被踢出去」。兩處：

兩者都是「否決封鎖」，但層次不同：禁封清單在決策產生前擋掉（那筆決策根本不存在，任何執行點都收不到）；自鎖保險在決策落地後讓它無效（決策存在、也寫進 set 了，只是 kernel 先放行）。前者是政策，後者是保險絲。

C　信任：誰說的來源 IP 算數

反向代理架構下，攻擊者 IP 不是封包來源，是標頭裡寫的值。TRUSTED_INGRESS_LIST（主機 B 的 Vector）與 TRUSTED_PROXY_IPS（主機 A 的平台）回答的是「哪些直連者送來的 CF-Connecting-IP 或 XFF 可以當真」。名單內的來源不是免檢，它自己的請求照樣過 WAF；差別只在它宣稱的「真正的來源」被採信，其餘直連者一律「誰打的記誰」。詳細在第 5 篇第一節。把這一類當成 IP 白名單去擴充，後果是讓那個 IP 可以陷害任何第三方。

D　放行決策：對某個來源明確放行

只有這一種是動態的。案件流程裡的 DecisionWriter 節點寫一筆 action=allow 的決策（平台合法的動作有五種：block、unblock、allow、escalate、observe），帶 ttl_seconds，od-bridge 拉回來後由 edl enforcer 寫進 allowlist.txt，經 :8500/edl/allow 給邊界設備抓。它的用途是「這個來源被判定為誤判或合作對象，在邊界上請放行，有效期若干小時」。與 A、B、C 三種固定清單相比，它會過期、由流程而非人手產生、而且只有一條落地路徑。下一節解釋為什麼。

三、那個不對稱：為什麼 allow 只落 EDL

三個 enforcer 對五種動作的支援，是 2026-09-13 逐檔對照原始碼確認的（decision_writer_handler.py 的 ENFORCEMENT_POINT_ACTIONS 表就是依此寫的，註解要求「不得憑印象增修」）：

不支援不是還沒做，是那個位置不需要「放行」這個動作。關鍵在一句話：

「放行」的意義是壓過其他封鎖來源。一個位置有幾個封鎖來源，決定了它需不需要獨立的放行清單。
位置|那裡有幾個封鎖來源|所以
:--|:--|:--
主機 B 的 nftables|一個：od-bridge 自己寫的 blocklist。沒有別的東西會往這個 set 加元素|要讓某個 IP 不被擋，把它從 blocklist 拿掉就完成了，那就是 unblock。再加一份可動態寫入的 allow set 不會多任何能力，反而多一個風險：流程的一筆決策就能把任意 IP 提升為「input chain 第一條 accept」，與自鎖保險混在一起，管理機與平台 IP 這種安裝時就該固定的清單從此可以被流程改寫
CrowdSec|一個由 API 管的：LAPI decisions。CrowdSec 的 whitelist 是 parser 層的設定檔（出廠只含 127.0.0.1），不是 LAPI 能動態寫的物件；LAPI 決策只有 ban、captcha 這類懲罰型別，沒有「allow」型別|放行同樣等於 unblock（刪 decision）。要動態 allow 得改設定檔並重載 agent，那不是執行點該做的事
邊界設備|很多：設備自帶的威脅情資、GeoIP 規則、其他來源的 EDL、人工寫的 deny 規則，加上我們這份 blocklist|一筆「這是誤判，請放行」若只做 unblock，只能移除我們自己那份清單裡的項目，設備其他來源的封鎖照樣擋。只有把它寫進一份獨立的 allow 清單、放在所有 deny 規則之上，才壓得過。這就是 allow 動作存在的唯一理由，也是它只在 EDL 有意義的理由

實作上的配套：DecisionWriter 在寫決策之前就依 ENFORCEMENT_POINT_ACTIONS 過濾，allow 配到 nftables 或 crowdsec 會被剔除並留一筆 warning（dropped_enforcement_points），一個都不剩時預設補 ['edl']。若沒有這層過濾，od-bridge 拉到手回 unsupported_action，整筆決策會從 applied 掉成 failed，處置中心看到的是「放行失敗」，而實際上是配錯執行點。這是 2026-09-13 的裁示，此前 SOC 流程範本裡的放行節點就是這樣失敗的。

四、allow 與 unblock：另一個常混的地方

網管視角裡「放行」和「解封」是同一件事，這套裡是兩個動作，行為差在三處：

兩套 EDL 對同一個 IP 的答案可能不同。主機 B 的 od-bridge EDL 是「兩份清單各自獨立，由設備決定優先序」；主機 A 的平台端 EDL 是「先算好結果，只給一份黑名單」。若邊界設備抓的是平台端那份，allow 之後又有新的 block 進來，該 IP 會重新出現在黑名單上；抓 od-bridge 那份的設備則因 allow 規則在上而繼續放行。要接哪一份，先想清楚你要的是哪種語意。

五、翻譯表：「我想把 X 加白名單」其實是想要哪一種

這張表是給拿到這套系統的網管工程師用的。左欄是常見的需求說法，中欄是它其實在問四種語意的哪一種，右欄是去哪設。

六、三個「白名單不是免檢」

七、常見誤解