今天是第二條主線「受控的網路與管理入口」的收尾。Day 09～17 從流量盤點與防火牆原理出發，逐步建立 OPNsense、WAN、VLAN、最小權限規則、跳板機與 OpenVPN。本篇再以 IDS／IPS 補上網路邊界的偵測與阻擋能力，最後回顧整條主線完成了什麼。

前面的防火牆章節已經建立兩項基礎：封包必須經過控制點，防火牆才有機會處理。狀態式規則可以判斷一筆連線是否符合網路政策，卻不能因此證明應用內容安全。後續建立的網路分段、預設拒絕與最小權限規則，會先阻止不符合政策的連線，但無法單靠防火牆規則辨認通過這個連接埠的流量是否具有可疑特徵。

前文也已經比較 IDS 與 IPS 的基本用途，以及檢查深度與部署位置如何限制可視範圍。本篇將這些概念展開成實際處理流程：先確認封包是否經過檢查位置，再說明流量重組、應用協定辨識、規則比對、告警與阻擋。最後才進入 Lab，先以 IDS 收集告警，再將一條已驗證的規則切換為 IPS 阻擋。

今天要解決的問題

1. IDS 與 IPS 的差別是什麼，為什麼看到告警不代表封包已被阻擋？
2. 感測器應放在哪裡，哪些流量可能完全不會經過 OPNsense？
3. 偵測引擎如何從單一封包一路判斷到 TCP 資料流與應用協定？
4. HOME_NET、規則集（Ruleset）、政策（Policy）、SID 與規則動作（Rule Action）分別控制什麼？
5. PCAP Live Mode、Netmap 與 Divert 三種擷取模式（Capture Mode）如何改變封包路徑？
6. 加密流量、誤判、效能與單台防火牆會留下哪些限制？

本文閱讀方式

• 完整理解技術與底層原理：依序閱讀全文。
• 掌握完成部署所需的基本概念：優先閱讀標有「⭐」的章節。
• 快速了解當天的部署內容：閱讀文末的 Lab／實作章節。
• 跟著系列建立完整系統：依照 GitHub 詳細部署文件 的天數順序操作。

Suricata 與 OPNsense 的關係

圖（一）Suricata 是 OPNsense 入侵偵測與防禦功能使用的網路威脅偵測引擎

Suricata 是一套開放原始碼的網路威脅偵測引擎（Network Threat Detection Engine），可以作為入侵偵測系統、入侵防禦系統與網路安全監控工具。它會從指定網路介面取得封包，解碼 IP、TCP／UDP 等網路協定，追蹤雙向連線、重組 TCP 資料流，再解析 HTTP、DNS、TLS、SSH 等應用協定。分析結果會與簽章規則比對，符合條件時可以留下告警。若 Suricata 位於實際轉送路徑，而且規則使用阻擋動作，也能直接丟棄封包。它還能輸出連線、應用協定與告警紀錄，供後續調查與監控系統使用。

Suricata 主要透過由多條簽章規則組成的規則集（Ruleset）辨認已知特徵，也常被稱為特徵庫。每條規則會描述要檢查的協定、來源與目的、流量方向、連線狀態，以及封包內容或應用協定欄位中應出現的特徵，並指定命中後要告警、丟棄或拒絕。偵測引擎會先依協定與網路流（Flow）篩選可能適用的規則，再比對重組後的資料與應用層欄位。特徵庫是一組可以描述網路行為與內容特徵的判斷條件。後文會再拆解單一規則的完整結構，以及規則集如何下載、啟用與更新。

OPNsense 本身是防火牆與路由平台，Suricata 則是 OPNsense 入侵偵測與防禦功能背後使用的偵測引擎。整體功能可以分成三個部分理解：

• OPNsense GUI：設定檢查介面、受保護網段、規則集、擷取模式與規則動作，並查詢告警。
• pf 防火牆：負責路由、NAT、狀態追蹤，以及允許哪些來源連到哪些服務。
• Suricata：分析通過所選介面的流量，進行協定解析、網路流追蹤與 TCP 資料流重組，再比對簽章或協定異常。

本文將 Suricata 取得並分析流量的位置稱為感測器（Sensor）。Suricata 如何取得封包，以及命中規則後只能告警或可以直接阻擋，由擷取模式與規則動作共同決定。

⭐ 從防火牆的可視範圍進入 IDS／IPS

入侵偵測系統（Intrusion Detection System，IDS）會分析流量並在規則命中時產生告警。入侵防禦系統（Intrusion Prevention System，IPS）則位於封包的轉送路徑中，除了偵測，也能丟棄符合阻擋條件的封包。兩者的第一個必要條件相同：感測器必須先取得封包。

一般的網路 IDS 可以從交換器的鏡像埠（SPAN Port）或網路 TAP 取得流量副本，即使 IDS 停止運作，也不一定會中斷原本的資料路徑。IPS 必須串接在來源與目的之間，封包通過檢查後才能繼續傳送，因此 IPS 的故障、效能不足與誤判都可能直接影響服務。OPNsense 將兩種模式整合在防火牆介面上。

圖（二）同 VLAN 流量不會經過 OPNsense。跨 VLAN 流量經過防火牆與路由器，Suricata 才有機會取得封包

原諒我同一張圖用這麼多次，但是他真的很重要。

只要實際路徑沒有經過所選介面，再完整的規則也不會產生結果。常見的可視範圍限制包括：

• 同一個 VLAN 的兩台主機可以直接透過交換器傳送訊框，不必經過 OPNsense。
• 同一台主機內的程序可能透過回送介面（Loopback）或本機通訊端交換資料。
• 獨立的儲存、叢集或管理網路若沒有經過 OPNsense，也不會被這裡的 Suricata 看見。
• 選擇 WAN、LAN 或 VLAN 父介面，會改變感測器觀察到的位址、方向與流量範圍。

介面位置還會影響位址轉換後看到的內容。若在 NAT 外側擷取，Suricata 可能只看到轉換後的公網或防火牆位址。在內側擷取則較容易保留實際內部主機位址。OPNsense 官方也提醒，WAN 原本就會被預設拒絕規則丟棄的入站封包，再由 WAN IPS 丟棄一次，不一定會增加實質保護。選擇介面前應先確認要保護哪一段流量，以及在這個位置能否辨認真正的來源與目的。

封包擷取（Packet Capture）是啟用規則前的第一項驗證工具。沒有告警時，先證明測試封包抵達擷取介面，再檢查規則。否則很容易在錯誤的位置反覆調整規則集。

硬體卸載會改變感測器收到的封包

網路卡與作業系統可以透過硬體校驗和卸載（Hardware Checksum Offload）、TCP 分段卸載（TCP Segmentation Offload，TSO）與大量接收卸載（Large Receive Offload，LRO）減少 CPU 處理工作。例如 TSO 讓作業系統先把較大的 TCP 資料區塊交給網路卡、驅動程式或虛擬化層，再切成實際送出的 TCP 區段。LRO 則可能先合併收到的連續區段，再交給作業系統。

圖（三）TSO 與 LRO 會改變作業系統及封包分析程序看到的 TCP 資料形態

卸載功能不一定完全由網路卡硬體執行。實體主機可能由網路卡與驅動程式共同處理。虛擬機還可能涉及虛擬網卡、虛擬機監視器（Hypervisor）與實體網路卡。這些功能有助於一般網路效能，卻可能讓 Suricata 看到尚未分段的大型資料區塊、已合併的接收資料，或尚未由網路卡完成的校驗和，與網路線路上實際傳輸的封包不同。OPNsense 因此要求啟用 IPS 模式前，先在介面設定中關閉硬體卸載功能。後文會說明 Netmap 如何把 Suricata 放入封包轉送路徑。若 VLAN 流量經過父介面，Netmap 必須套用在支援的實際父介面，不能只依畫面上的邏輯 VLAN 名稱判斷。

Suricata 如何從封包辨認可疑行為

前面的防火牆章節中，曾用 IP、連接埠、網路流、協定與簽章說明 IDS／IPS 可以看見哪些資訊。現在把這些名詞展開成 Suricata 的實際分析順序。Suricata 不只逐一搜尋每個封包中的字串，它能檢查 IP 與 TCP／UDP 標頭以外的資料，並辨認應用協定與內容，這類能力通常稱為深度封包檢查（Deep Packet Inspection，DPI）。封包進入偵測引擎後，會依協定與連線狀態逐步建立更多上下文：

圖（四）Suricata 逐步建立連線與應用協定上下文，再篩選及比對適用的簽章規則

因此，規則可以只檢查封包標頭，也可以在重組後的 TCP 資料流或應用層欄位中比對。連接埠只能表示資料送往哪個通訊端，不能保證實際內容就是該連接埠慣用的協定。應用層解析器比單憑 TCP 80 判定 HTTP 提供更可靠的依據。

Suricata 也能記錄網路流、應用協定、中繼資料與協定異常，用於網路安全監控（Network Security Monitoring，NSM）。偵測方式可以依已知特徵比對簽章，也可以從不符合協定規範的行為產生異常事件。

⭐ 一條 Suricata 規則如何表達判斷條件

Suricata 官方將規則分成三個主要部分：動作（Action）、標頭（Header）與選項（Options）。我們示範一個規則：

alert tcp $EXTERNAL_NET any -> $HOME_NET 5432
      (msg:"範例：外部來源嘗試連線 PostgreSQL";
       flags:S; sid:1000001; rev:1;)

常見規則動作的意義如下：

• alert：產生告警，封包可繼續處理。
• drop：在 IPS Mode 丟棄封包並產生告警。
• reject：丟棄封包，並視協定向一端或兩端回覆拒絕訊息。
• pass：符合條件後停止繼續檢查該封包，使用時必須特別審查範圍。

SID 讓管理者能追蹤是哪一條簽章（Signature）命中。rev 則用來辨識規則內容的更新。告警紀錄還需要保留規則來源、分類與時間，因為同一項測試在規則集更新後可能得到不同結果。

HOME_NET 表示受保護網路

HOME_NET 與 EXTERNAL_NET 是規則使用的位址變數。HOME_NET 應包含要被視為內部或受保護的網段，EXTERNAL_NET 通常代表 HOME_NET 以外的位址。它們會影響規則中的來源、目的與方向判斷。

HOME_NET 設定範圍過窄，可能讓原本針對內部服務的規則無法命中。設定成 any 時，若 EXTERNAL_NET 定義為 HOME_NET 的反向集合，甚至可能無法形成有效的位址集合。因此應列入實際受保護的網段，不能把所有可能出現的位址一律加入。

⭐ 三種擷取模式如何取得封包

OPNsense 的擷取模式（Capture Mode）決定 Suricata 從哪裡取得封包，以及能否控制原封包繼續傳送。前面介紹的規則動作則決定命中後要告警、丟棄或拒絕。兩者是不同設定，必須分開理解。已啟用的規則集會向 Suricata 提供簽章規則。Suricata 解析封包後，才與規則比對。

PCAP Live Mode（IDS）模式：取得封包副本

PCAP Live Mode 會從指定介面擷取封包副本交給 Suricata，原封包沿著 OPNsense 原有的網路路徑處理。Suricata 可以分析副本並留下告警，但無法利用副本阻擋原封包，因此這個模式只能作為 IDS。

圖（五）PCAP Live Mode 只將封包副本交給 Suricata，因此能留下告警但不能阻擋原封包

Netmap（IPS）模式：控制原封包是否繼續傳送

Netmap 是一套高速封包輸入與輸出框架。封包檢查與攻擊辨識由 Suricata 負責。網路介面會使用環形緩衝區排列等待接收或送出的封包。Netmap 將這些緩衝區映射到使用者空間，讓 Suricata 能以批次方式直接讀取及送回封包，減少重複複製資料與頻繁執行系統呼叫的額外負擔。

OPNsense 本身建立在 FreeBSD 上，Suricata 則是同一台 OPNsense 內執行的程序。Netmap 會先把所選介面的原封包交給 Suricata。規則未命中或只命中 Alert 時，Suricata 再把封包交還 OPNsense 的網路堆疊，由 pf、NAT 與路由繼續處理。命中 Drop 或 Reject 時，Suricata 會停止轉送並留下紀錄。封包全程都在同一台 OPNsense 內處理，沒有離開設備再重新進入。

圖（六）Netmap 讓 Suricata 位於原封包的處理路徑中，命中 Drop 或 Reject 規則時可以停止轉送

Netmap 需要驅動程式提供一致的封包緩衝區。原生支援模式可以直接操作介面的緩衝區。模擬模式則透過相容層支援其他介面，效能與 VLAN 處理能力可能受到限制。OPNsense 因此要求 IPS 選擇支援 Netmap 的實際網路介面。VLAN 流量則選擇承載它的父介面，並關閉硬體卸載功能。切換後只要 Netmap、驅動程式或 Suricata 任一環節無法正常轉送，介面就可能失去連線，因此事前必須保留另一條管理路徑或主控台。

Divert（IPS）模式：由防火牆規則選擇流量

Divert 不直接接管所選介面的全部流量，他先由 pf 防火牆規則判斷哪些封包需要檢查。封包命中帶有 Divert-to 動作的規則後，pf 會把原封包導向 Suricata 監聽的 Divert 通訊端。Suricata 完成檢查後，再決定讓封包返回轉送路徑，或依 Drop／Reject 動作阻擋。沒有命中 Divert-to 規則的流量不會送入這個檢查流程。

管理者可以使用一般防火牆規則的比對條件，選擇要送入 Suricata 的流量，包括介面與方向、IPv4／IPv6、TCP／UDP／ICMP 等協定、來源與目的 IP、網段或 Alias，以及來源與目的連接埠。例如，只把從外部網路進入 Web 伺服器 TCP 443 的封包送入 Suricata，同時略過不需要檢查的備份或監控流量。Divert-to 決定哪些封包接受檢查，Suricata 規則則決定檢查後要告警、放行或阻擋。

圖（七）Divert 先由 pf 規則選擇流量，再由 Suricata 決定放行、告警或阻擋

這種選擇性導流可以減少不必要的檢查負擔，卻也會增加規則順序與比對條件的管理工作。當 Divert-to 規則生效，而負責接收封包的 Suricata 服務或監聽程序已停止時，OPNsense 會丟棄符合規則的封包。因此啟用前必須同時驗證防火牆規則、Suricata 監聽程序與回復路徑。

三種模式的差異可以整理如下：

擷取模式與規則動作必須同時成立

PCAP Live Mode 即使遇到 Drop 規則，也只能分析副本，不能阻擋原封包。Netmap 或 Divert 能控制原封包。命中 Alert 規則時封包繼續傳送，命中 Drop 或 Reject 規則時才會阻擋。

本次使用 PCAP Live Mode 建立偵測基準，再切換 Netmap。Divert 能由防火牆規則更精確地選擇送入感測器的流量，但牽涉額外的封包導向條件，不放入本次實作。

⭐ 規則如何生效並產生告警

剛啟用 OPNsense 入侵偵測功能時，Suricata 引擎可以運作，但沒有規則就無法依簽章偵測威脅。規則的設定與命中結果如下：

Ruleset 提供候選規則，規則管理方式則分成 Policy 與單條手動覆寫。Policy 位於 Services → Intrusion Detection → Policy，可以依 Ruleset、原始 Action 與規則中繼資料篩選一批規則，再統一指定 Disabled、Alert 或 Drop。多筆 Policy 重疊時，優先順序編號（Priority Number）較低者先套用。OPNsense 官方建議大量或長期管理時使用 Policy，逐條修改容易累積大量覆寫並拖慢 GUI。本次 Lab 只驗證一條明確的 SID，因此直接在 Administration → Rules 修改。手動修改的套用來源會標示為 __manual__。規則下載後，還須啟用所需規則。

例如，要將 ET open/emerging-scan.rules 中目前 Disabled 的規則批次啟用為 Alert，可以建立以下 Policy：

這項設定會影響 Scan 分類中所有符合條件的規則，並非只修改一個 SID。若只想驗證單一規則，直接使用 Rules 頁面的 Edit 較精確。若要長期維護整個分類，使用 Policy 比逐條建立手動覆寫更容易審查。

Suricata 本身也能將告警、網路流、HTTP、DNS、TLS、Drop 與統計資料寫成 EVE JSON，供其他 Log 或事件分析工具處理。同一筆連線的事件可以利用 flow_id 互相關聯。fast.log 則是較精簡的告警紀錄。OPNsense 已將必要事件整理到 Alerts 頁面，本次先從 GUI 建立可重現的證據，不在這裡提前展開後續的集中監控架構。

一次啟用所有規則分類（Category）會增加記憶體、CPU、告警雜訊與誤判排查成本，也會讓管理者難以說明每條 drop 規則保護的服務。ET Open 適合入門與一般偵測。受監管環境還需要依風險與合規要求建立其他防護措施。

較穩健的導入順序是先選擇與現有服務相符的分類，以 Alert 觀察正常流量，再把能穩定辨識、具有明確處置方式的單一規則改成 Drop。每次更新後，重新檢查命中量、規則修訂與例外是否合理。

加密流量、誤判與漏判

Day10 防火牆種類與部署位置已說明 TLS 終止位置會限制防火牆的可視範圍。後續導入 Cloudflare 後，HTTP 明文會先在 Cloudflare Edge 出現，因此公開網站的應用層檢查主要交給 Cloudflare 的 Web 應用程式防火牆（WAF）。Cloudflare 會再以 Full (strict) 建立通往 Nginx 的 TLS 連線。位於中間的 OPNsense 與 Suricata 仍只能分析網路行為與部分 TLS 中繼資料，無法直接檢查完整的 HTTP 內容。

簽章偵測可能出現兩種判斷錯誤：

• 誤判（False Positive）：正常流量被判定為可疑。若規則使用 Drop，可能直接造成服務中斷。
• 漏判（False Negative）：真正的惡意流量沒有命中規則。未知手法、加密內容或繞過 Sensor 的路徑都可能造成漏判。

因此，Alert 是待查線索，應結合封包、主機與服務紀錄判讀。未觸發告警的流量也需要其他監控方式補足視野。規則應先使用 Alert 觀察正常流量，確認 SID、來源、目的與服務用途後，再把穩定且有明確處置方式的規則改成 Drop。

本次實驗：驗證 Suricata 的可視範圍與 IDS／IPS 動作

本次依照路徑、偵測、阻擋的順序進行。先讓 Suricata 以 IDS 模式取得封包副本，確認測試流量確實經過 WAN 並命中規則，再將同一條規則改成 Drop 並切換 IPS。這樣可以分辨問題來自封包路徑、規則設定，還是阻擋模式。

GitHub 實作文件：Day 18｜在網路邊界發現並阻擋威脅：OPNsense Suricata IDS／IPS 的運作與實測

部署摘要

驗證一：建立回復入口並停用硬體卸載

Suricata 會增加記憶體與封包處理負擔，因此先確認 fw01 至少有 3 GB RAM，下載最新的 config.xml，並建立短期快照。切換 Netmap 前保持 PVE 主控台可用，避免網路中斷後失去回復入口。
接著進入 Interfaces → Settings，勾選以下三個以 Disable 開頭的選項：

Disable hardware checksum offload
Disable hardware TCP segmentation offload
Disable hardware large receive offload

圖（八）三個 Disable 選項都要勾選，讓 Suricata 取得一致的封包形態

這些欄位採負向命名，勾選代表停用硬體校驗和、TSO 與 LRO 卸載。儲存並套用後依提示重新啟動，再確認 WAN、內部介面與管理連線正常。

驗證二：IDS 擷取範圍與 HOME_NET 符合規劃

進入 Services → Intrusion Detection → Administration → Settings，啟用 Suricata，將 Capture mode 設為 PCAP live mode (IDS)，Interfaces 先選 WAN。這個模式只分析封包副本，即使規則動作是 Drop，也不會阻擋原封包。

圖（九）先以 PCAP Live Mode 在 WAN 建立只告警的 IDS 驗證環境

HOME_NET 改為 OPNsense 後方需要保護的網段：

10.77.10.0/24
10.77.20.0/24
10.77.30.0/24
10.77.40.0/24
10.77.50.0/24
10.77.60.0/24

圖（十）HOME_NET 只加入本次需要保護與辨識的內部網段

模擬 WAN、Ceph 與 Corosync 網路不在這次 Suricata 的保護路徑中，因此不加入 HOME_NET。這項設定讓 HOME_NET 對應受保護範圍，不把所有出現在環境中的位址全部加入。

驗證三：下載規則集並只啟用測試規則

到 Services → Intrusion Detection → Administration → Download 下載完整的 ET open/emerging.rules，取得候選規則。接著啟用本次測試所需的 SID。

接著進入 Administration → Rules，搜尋 SID 2010939，按 Edit 勾選 Enabled，將 Action 設為 Alert，再按 Save 與 Apply。

驗證四：測試流量確實經過 WAN

測試來源使用 PVE L0，目標使用自己的 app01 10.77.20.31。先在 PVE L0 查詢實際路由：

ip route get 10.77.20.31

若結果顯示流量經過原本的上游路由器，Suricata 就看不到這筆封包。這時只為本次目標加入暫時的 /32 路由，下一跳使用 fw01 當下的 WAN 位址：

ip route replace 10.77.20.31/32 via 192.168.0.84 dev vmbr0
ip route get 10.77.20.31

在 OPNsense 開啟 Interfaces → Diagnostics → Packet Capture，選擇 WAN、IPv4 與 TCP，並以 PVE L0 192.168.0.146 作為 Host Address。開始擷取後，回到 PVE L0 對自己的 app01 執行有限範圍探測：

sudo nmap -sS -Pn -p 22,80,443,5432 10.77.20.31

停止擷取後，若能找到來源 192.168.0.146、目的 10.77.20.31 的 TCP SYN，就能在修改規則前先確認路徑。若 Packet Capture 沒有顯示結果，也可以繼續利用下一節的 Suricata Alerts 核對 Interface、來源與目的。三者一致，同樣能確認 Suricata 確實在 WAN 看見這筆測試流量。若 Packet Capture 與 Alerts 都沒有結果，才應先修正路由或擷取介面，不要繼續更換 Ruleset 或規則動作。

證明一：PCAP Live Mode 命中規則後只留下告警

實測由 ET Open SID 2010939 偵測送往 PostgreSQL TCP 5432 的可疑入站探測。PCAP Live Mode 的預期紀錄如下：

Interface：WAN
Action：allowed
Source：PVE L0 的位址
Destination：10.77.20.31
Destination Port：5432
SID：2010939
Signature：ET SCAN Suspicious inbound to PostgreSQL port 5432

圖（十一）Alert 詳細資料確認 SID 2010939 命中送往 PostgreSQL TCP 5432 的流量，設定動作為 Alert。實際的 allowed 紀錄可在圖（十四）對照。

allowed 表示規則已命中並留下告警，但 IDS 沒有丟棄封包。

證明二：Netmap 配合 Drop 可以阻擋原封包

IDS 結果穩定後，到 Administration → Rules 搜尋 SID 2010939，按 Edit，只將這條已驗證規則的 Action 改為 Drop，再按 Save 與 Apply。接著回到 Settings，把 Capture mode 從 PCAP live mode (IDS) 切換成 Netmap (IPS)，套用後重做完全相同的 Nmap 測試。

圖（十二）只將已驗證的 SID 2010939 從 Alert 改為 Drop

圖（十三）將擷取模式切換為 Netmap，讓 Suricata 能控制原封包是否繼續傳送

回到 Alerts 搜尋相同 SID，處理結果應由 allowed 變成 blocked 或 drop。這項變化才證明 Suricata 已從偵測切換為阻擋。

WAN 防火牆原本就可能拒絕這筆未授權連線，因此 Nmap 的畫面在切換前後不一定改變。本次以相同封包、相同 SID 的 Suricata 規則動作從 allowed 變成 blocked／drop，證明 IPS 已實際執行規則。

圖（十四）相同 SID 在切換前顯示 allowed，切換至 Netmap 與 Drop 後顯示 blocked

畫面保留了切換前後的紀錄，可以直接確認相同 SID 的處理結果已由 allowed 變成 blocked。

實作結束後，在 PVE L0 移除暫時路由：

ip route del 10.77.20.31/32

最後確認正常管理與服務流量可用，即完成本次實驗。

Lab 驗證對照

正式環境注意事項

正式環境應先在只告警模式建立基準，再依服務擁有者、流量方向與誤判處理流程逐步啟用 Drop。規則集來源、版本、啟用方式、例外、負責人與變更紀錄都應納入管理。切換擷取模式前則要保留不依賴受檢查網路的主控台與設定回復方式。效能評估應同時記錄 CPU、延遲、吞吐量、記憶體與擷取丟包數。

今天完成了什麼

• 從封包路徑界定 Suricata 的可視範圍，理解同 VLAN、加密流量與部署位置造成的限制。
• 分清楚 HOME_NET、規則集、Policy、SID、擷取模式與規則動作的責任。
• 以路由、WAN 封包擷取或 Alerts 的 Interface 與位址資訊確認受控測試流量確實進入 Suricata 的感測位置。
• 讓同一條 ET Open 規則先以 IDS 留下告警，再切換為 IPS Drop。
• 比較相同 SID 從 allowed 變成 blocked，確認擷取模式與規則動作必須同時成立。

主線二完成了什麼

至此，第二條主線已經完成。下圖（十五）是到目前為止我們已完成的核心部分。

圖（十五）主線二完成 OPNsense 網路邊界、OpenVPN 遠端存取與 jump01 受控 SSH 入口

這十天建立的防火牆觀念、網路與管理路徑包括：

• 從封包路徑、五元組與狀態表理解無狀態和狀態式封包過濾，以及新連線與回程流量如何被判斷。
• 比較網路、主機、虛擬化平台與代理防火牆的檢查深度和部署位置，釐清每個控制點能看見的流量。
• 盤點服務暴露面與跨區流量需求，依防火牆可見的封包路徑規劃信任邊界。
• 在 PVE 上建立 OPNsense，完成 WAN 上網、來源 NAT，以及管理與服務 VLAN 的介面、閘道和跨網段路由。
• 使用 Alias、介面群組與規則順序，建立 DNS、NTP、對外更新及內部網段阻擋的共同政策，並以允許與拒絕測試核對結果。
• 將 PVE 管理流量逐台切到 OPNsense，建立 jump01，以目的地 NAT、SSH 金鑰、ProxyJump 與個人轉送限制收斂主機管理入口。
• 建立 OpenVPN 的遠端身分、路由與分級授權，驗證管理帳號、一般帳號及撤銷後的存取結果。
• 在確定封包經過感測位置後，驗證 Suricata 的 IDS 告警與 IPS 阻擋。同時保留單台 OPNsense、同 VLAN 流量及加密內容的可視範圍限制。

下一篇預告

下一篇開始進入主線三：可以切換、也可以復原的服務。這條主線會從內部 CA 與 PostgreSQL 節點出發，逐步建立串流複寫、etcd 與 Patroni 的角色協調，再加入 Nginx、HAProxy 與 Keepalived 提供固定服務入口，最後以備份、監控和故障演練驗證服務能否切換及復原。

Day 19｜從金鑰到信任鏈：使用 step-ca 為 PostgreSQL HA 建立專用內部 CA會先從加密、雜湊與數位簽章理解憑證如何證明服務身分，再建立 PostgreSQL 專用的內部 CA，為後續資料庫 TLS 連線準備可驗證的信任基礎。

參考資料

• OPNsense｜Intrusion Prevention System
• OPNsense｜Netmap 與網路排錯
• OPNsense｜Performance
• OPNsense｜Interfaces Settings
• Suricata｜Rules Format
• Suricata｜Netmap
• Suricata｜EVE JSON Output
• iT 邦幫忙｜IDS、IPS 與 Suricata