安裝包裡有六套開源元件，但 EDL 不是任何一套產出的，它是自建的 od-bridge 產出的。這篇把 EDL 的來源、落地路徑、對外 URL、以及「誰該讀它、誰不該讀它」一次講清楚。特別要說的是：不建議拿 Linux 的軟體防火牆去吃這份 EDL，理由在第六節。

先講結論。EDL 是 od-bridge 把平台核可的封鎖決策「翻譯成純文字檔」再用 HTTP 供應出去的產物，格式是一行一個 IP，設計給企業既有的邊界防火牆（Palo Alto、FortiGate 這類支援 External Dynamic List 的設備）定期抓取。安裝包內的六套開源元件沒有任何一套讀它；防禦節點自己的封鎖靠的是 nftables 與 CrowdSec，那兩條是 od-bridge 直接寫入的，不經過 EDL 檔。沒有專業設備的環境，EDL 產出來就只是擺著，這是預期狀態，不是故障。另外平台本身還自產一份只含黑名單的 EDL（第四節），給沒有防禦節點的部署用。

一、EDL 是什麼

EDL 是 External Dynamic List 的縮寫，來自 PAN-OS 的用語。概念很單純：防火牆上設一條規則，來源不寫死 IP，而是指向一個 URL；防火牆依排程重新抓那個 URL，抓到的內容就是當下的清單。它有三個特性，後面的設計都是從這三點推出來的：

二、EDL 從哪來：決策落地的第三條路

第 3 篇講過，事件送上平台建案、流程核可封鎖之後，決策是由 od-bridge 拉回防禦節點的（每 5 秒輪詢一次 /api/open_defense/decisions）。每筆決策帶一個 enforcement_points 欄位，寫明這筆決策要落在哪些執行點；od-bridge 拿自己 .env 裡的 MY_ENFORCEMENT_POINTS（預設 nftables,crowdsec,edl）與它取交集，交集內的每個執行點各跑一個 enforcer。EDL 是三個 enforcer 之一，與 nftables、CrowdSec 平行，彼此不相依。

edl enforcer 的實作重點只有一個：它是 reconciler，不是 appender。理由回到第一節的第一個特性：EDL 格式沒有 TTL 欄位，追加式寫法永遠刪不掉到期項目，清單只會長到設備拒絕載入。所以 od-bridge 把權威集合放在 state.json（每筆自帶 expires_at），每次收到決策或每 60 秒的 prune 都重繪整份 blocklist.txt 與 allowlist.txt。新增會累積，到期會自己掉出去。寫檔走 temp file 加 os.replace，設備抓到一半不會讀到半截檔。

三、路徑與 URL：查問題時看這張表

空清單回 200 而不是 404，是刻意的。還沒有任何封鎖時 /edl 回一個空的 200。若回 404，PAN-OS 會沿用上一次抓到的內容，等於把一份過期的黑名單靜默釘在設備上。所以 curl 看到「200 但沒內容」是正常狀態，代表目前沒有生效中的封鎖。

四、另一份 EDL：主機 A 平台端自產的黑名單

前三節講的都是主機 B 上 od-bridge 那份。平台本身還有一份：主機 A 每分鐘用排程把該企業所有有效的封鎖決策渲染成一個 blocklist.txt，同時可從檔案分享與 HTTP 取得。兩份的內容本來就不同，看到不一致不要當成同步失敗。

為什麼要有第二份：沒有防禦節點的部署也能接防火牆。只裝主機 A、不裝主機 B 的環境，決策沒有任何執行點會落地，平台端這份就是它唯一的出口；有主機 B 的環境，它則是不依賴 od-bridge 存活的備援來源。

要接哪一份，看你要的語意。需要「放行清單壓過其他封鎖來源」（第 7 篇第三節）、或設備已經在抓主機 B 的其他服務，接 od-bridge 那份；沒有主機 B、想從網路磁碟讀檔、或只想要一份「已經算好誰該封」的黑名單，接平台端那份。不要兩份都接進同一台設備：同一個 IP 在兩邊的答案可能不同（第 7 篇第四節），設備會依規則順序取其一，排錯時很難看出是哪份說了算。

五、誰該吃它：三個執行點各自的消費者

三個 enforcer 平行，但消費者完全不同。這張表是判斷「我的環境該接哪一條」的依據：

EDL 的正確消費者是「已經站在攻擊者與網站之間」的邊界設備。典型是企業既有的 Palo Alto（EDL）、FortiGate（External Resource 的 IP address 類型）、或其他能訂閱 URL 清單的次世代防火牆。設備上只要做兩件事：新增指向 http://192.168.0.112:8500/edl 的外部清單、以它為來源建一條 deny 規則；再把設備的抓取來源 IP 加進主機 B 的 ADMIN_IPS。這是「防禦節點以外還有第二道邊界」以及「多台防禦節點想共享一份黑名單」這兩種場景的解法。

六、不建議用 Linux 軟體防火牆吃 EDL

沒有專業設備的讀者第一個想到的通常是：那我在某台 Linux 上寫個 cron，定期 curl 這個 URL 塞進 iptables 或 nftables，不就有邊界防火牆了？三種常見的放法都不建議，理由各不相同。

不建議的核心理由只有一個：EDL 是為「只能吃 URL 清單」的設備設計的最低共同格式，它把 TTL、增量、原子性全部丟給產出端。Linux 主機從來不受這個限制，它有 CrowdSec bouncer 這條帶 TTL 與增量的正規路徑，也有 od-bridge 直接寫 nftables 的實作可以參考。拿 Linux 去吃 EDL，是主動放棄較好的介面去遷就較差的格式。

那沒有專業設備的讀者怎麼辦？誠實的答案是：在純 tunnel 部署下，EDL 沒有適合的落點，nftables 就是這個架構裡唯一有效的邊界（第 5 篇第二節的表格已經講過它擋得住什麼）。若手邊有 pfSense 或 OPNsense 這類自帶 URL 清單 alias 功能的防火牆發行版當網路邊界，那是可以接 EDL 的（它們的 URL table alias 本身就處理排程抓取與全量替換），但這已經是「有邊界設備」的場景，不是 Linux 軟體防火牆。本系列沒有實測這兩者，設定方式請以其官方文件為準。

七、驗證：三分鐘確認整條路是通的

在 ADMIN_IPS 內的任一台主機執行（不在清單內會逾時，這不是 EDL 壞了，是第三節最後一列，平台端那份則看 OD_EDL_ALLOWED_IPS）：

# 1. 現況：預期 200，內容為空或一串 IP
curl -s -D - http://192.168.0.112:8500/edl

# 2. 送一筆測試事件，讓平台建案並產生封鎖決策（在主機 B 上）
sudo bash /opt/integrated-waf/install.sh --test-event

# 3. 平台核可封鎖後最多 5 秒，測試 IP 應出現在清單裡
curl -s http://192.168.0.112:8500/edl

# 4. 對照主機端檔案與權威狀態（含到期時間）
sudo cat /opt/integrated-waf/od-bridge/state/edl/blocklist.txt
sudo cat /opt/integrated-waf/od-bridge/state/edl/state.json

# 5. 等 TTL 到期後再抓一次，該 IP 應消失（最晚多等 60 秒的 prune 週期）

第 3 步與第 4 步的內容應一致，因為 /edl 就是原樣讀 blocklist.txt 回出去。若檔案有內容而 URL 是空的，先查 od-bridge 容器有沒有在跑（docker ps 找 od-bridge）；若 URL 逾時，查 .env 的 ADMIN_IPS。

八、常見誤解