前一篇從防火牆的發展理解了無狀態封包過濾（Stateless Packet Filtering）、狀態檢查（Stateful Inspection）與應用感知檢查（Application-aware Inspection）為什麼陸續出現。光知道防火牆能檢查封包，還不足以決定一條安全限制應該放在哪裡。
例如只允許管理員連線 PVE 8006，可以先由 OPNsense 限制來源網段，再由 PVE 防火牆保護管理介面，最後由 PVE 驗證使用者身分。三層看到的資訊不同，負責的工作也不同。
今天處理兩個問題：防火牆能檢查到多深，以及它部署在流量路徑的哪個位置。
本文閱讀方式
- 完整理解技術與底層原理：依序閱讀全文。
- 掌握完成部署所需的基本概念：優先閱讀標有「⭐」的章節。
- 快速了解當天的部署內容：閱讀文末的 Lab／實作章節。
- 跟著系列建立完整系統：依照 GitHub 詳細部署文件 的天數順序操作。
防火牆的名稱經常被放在同一份清單裡比較，而它們可能在回答不同問題。要確認一套系統屬於哪一類防火牆，必須同時確認它能檢查哪些資訊，以及它部署在流量路徑的哪個位置。
第一個問題是檢查深度（Inspection Depth）：它只能讀取 IP 與連接埠，還是能理解連線狀態、HTTP 請求或攻擊特徵？
第二個問題是部署位置（Deployment Location）：它位於網路邊界、虛擬化平台（Hypervisor）、單一作業系統，還是應用程式前方？
回答這兩個問題後，才有辦法完整描述一套防火牆。以本系列的 OPNsense VM 為例：從部署位置來看，它是虛擬防火牆（Virtual Firewall）與網路防火牆（Network Firewall）。從檢查能力來看，它預設提供狀態式防火牆，啟用 Suricata 後還能增加 IDS／IPS 能力。
防火牆做決策以前，必須先取得可用資訊。越往上理解應用協定，能建立的規則通常越細，運算成本、加密處理與誤判風險也會隨之增加。
圖（一）從 OSI 模型理解各層可以取得的網路資訊
無狀態封包過濾將每個封包視為獨立事件，依來源 IP、目的 IP、協定、連接埠或 TCP 旗標（Flag）決定允許與拒絕。它的優點是處理邏輯直接，缺點是不知道封包是否屬於先前已建立的合法連線。
它主要使用第 3 層（Layer 3）的 IP 與協定，以及第 4 層（Layer 4）的 TCP／UDP 連接埠和 TCP 旗標。
狀態式防火牆會在第一個新連線封包通過規則後建立狀態，後續符合該連線方向、位址、連接埠與協定狀態的封包可以依狀態表（State Table）處理。
相同來源再次發起一筆新的 TCP 連線時，因為來源連接埠、序號與連線狀態不同，必須重新比對防火牆規則。OPNsense 的一般規則就是以狀態式過濾（Stateful Filtering）為基礎。
圖（二）狀態式防火牆允許符合既有狀態的回程封包
它同樣以第 3 層與第 4 層為主要判斷範圍，再加入 TCP 連線狀態、逾時與回程方向等連線上下文。
在進入代理防火牆前要先了解 TLS 終止。代理防火牆與 WAF 需要理解第 7 層（Layer 7）的應用內容。當 HTTPS 使用 TLS 加密時，位於 TLS 終止點以前的設備通常只能看到來源、目的、TCP 443、連線狀態與部分 TLS 中繼資料（Metadata），無法直接讀取完整的 HTTP 主機名稱、路徑、標頭與本文。
以本系列的 HTTPS 路徑為例：
需要檢查完整 HTTPS 請求的代理伺服器或 WAF，必須位於 TLS 終止之後，或由自己負責 TLS 終止。這項設計會決定憑證（Certificate）、私鑰（Private Key）、解密後流量、紀錄（Log）與運算負載集中在哪一層。
連線層閘道（Circuit-level Gateway）與應用程式代理（Application Proxy）都可以歸在代理防火牆這個大類。兩者都會把用戶端（Client）與伺服器（Server）之間的連線拆開，由代理伺服器代表用戶端建立另一條連線。差異在於它們理解應用內容的深度。
圖（三）連線層閘道將用戶端與伺服器的通訊分成兩段
以 SOCKS5 為例，UDP 透過 UDP ASSOCIATE 建立轉送關聯，再由代理伺服器轉送資料報（Datagram）。
圖片來源：Palo Alto Networks｜What Is a Circuit-Level Gateway?
連線層閘道關注的是工作階段或傳輸層連線（Transport Connection）是否可以建立。以 SOCKS 代理伺服器為例，用戶端先連到代理伺服器，再由代理伺服器建立另一條到目的端的連線。
它能隱藏內部用戶端並控制連線方向，通常不會理解 HTTP 參數、SQL 指令或應用程式的商業邏輯。它與應用程式代理的共同點是用戶端與後端（Backend）之間會拆成兩段連線。差異在於理解應用內容的深度。
它主要根據第 4 層的連線資訊，以及接近第 5 層（Layer 5）的工作階段資訊進行控制，通常不解析完整的第 7 層內容。
應用程式代理會終止用戶端連線，再以自己的身分建立後端連線。因為它理解特定應用協定，所以能依協定內容做更細的處理。
以 Nginx 反向代理（Reverse Proxy）為例，它可以讀取 HTTP 主機名稱、路徑與標頭，終止 TLS，再把請求送往選定的後端。這也是它能提供虛擬主機（Virtual Host）、路徑路由（Path Routing）、速率限制（Rate Limit）或標頭調整的原因。
應用程式代理工作在第 7 層。要進一步提供 WAF 能力，還需要具備 HTTP 安全規則、請求本文檢查、攻擊特徵比對、允許／阻擋動作（Allow／Block Action）、規則更新，以及誤判調校與紀錄功能。Nginx 基本反向代理負責轉送與路由。加入對應的 WAF 模組（Module）或外部 WAF 後，才會取得這些安全檢查能力。
WAF 專門檢查 HTTP／HTTPS 對話，可以使用 URL、方法（Method）、標頭（Header）、Cookie、參數（Parameter）與本文（Body）判斷網站請求是否符合政策或攻擊特徵。例如，它可能辨識 SQL 注入（SQL Injection）與跨網站指令碼（Cross-Site Scripting，XSS）的常見形式。
WAF 工作在第 7 層，只處理它能理解的網站應用程式協定（Web Application Protocol）。
WAF 專注於 HTTP／HTTPS。SSH、etcd Peer Traffic 與 PostgreSQL Replication 由網路防火牆、主機防火牆及各服務本身的安全機制保護。網站應用程式本身需要執行輸入驗證（Input Validation）、身分驗證（Authentication）與授權（Authorization）。
實務上還要分清楚偵測／監控模式（Detection／Monitoring Mode）與阻擋模式（Blocking Mode）。前者先記錄命中結果，適合觀察誤判。後者才會實際拒絕請求。直接把未調校的規則切到阻擋模式，可能連正常流量一起擋住。
入侵偵測系統（Intrusion Detection System，IDS）會分析經過感測器（Sensor）的流量並產生告警（Alert）。入侵防禦系統（Intrusion Prevention System，IPS）位於線上路徑（Inline Path），符合阻擋條件時可以直接丟棄（Drop）封包。
防火牆政策（Firewall Policy）主要限制此來源是否可以使用這項服務。IDS／IPS 則進一步判斷被看見或已允許的流量是否具有攻擊特徵。兩者處理不同問題，並在同一條安全路徑上互相補充。
IDS／IPS 可以從第 3／4 層的位址、連接埠、流量與 TCP 狀態，一路檢查到第 7 層的協定、Payload 與特徵碼（Signature）。實際可見範圍取決於感測器位置、加密狀態與啟用的規則集（Ruleset）。
下一代防火牆（Next-Generation Firewall，NGFW）在狀態式防火牆的第 3／4 層控制上加入第 7 層的應用程式識別（Application Identification）與使用者感知能力，並經常整合 IDS／IPS、網址過濾（URL Filtering）及 TLS 檢查（TLS Inspection）。它的重點是辨認「這是什麼應用、由誰使用、內容是否符合安全政策」，不只依連接埠判斷服務。
整合式威脅管理（Unified Threat Management，UTM）的重點是把防火牆、VPN、IDS／IPS、惡意程式防護（Anti-malware）、網站／郵件過濾（Web／Mail Filtering）等多項閘道安全（Gateway Security）功能整合在同一套設備與管理介面。
NGFW 強調應用識別與細緻控制，UTM 強調多項安全服務的集中整合。現代產品經常同時具備兩邊的功能。OPNsense 加上 Suricata、VPN 與各項外掛（Plugin）後也能提供部分相近能力，實際範圍取決於已安裝及啟用的功能。
檢查能力回答「看得到什麼」，部署位置則決定「哪些流量一定會經過它」。即使規則寫得很完整，只要封包沒有進入該控制點，它就無法判斷或留下紀錄。
網路防火牆位於不同網路／區域的路由路徑上，適合控制 WAN、VPN、VLAN 等不同區域之間的流量。本系列由 OPNsense 負責這一層。
部署位置決定網路防火牆的可視範圍。兩台 VM 位於同一個 VLAN 時，可以由第二層橋接器（Layer 2 Bridge）直接交換封包。OPNsense 只會看到送往其路由介面的流量。
圖（四）同 VLAN 流量直接由交換器轉送
部署位置：不同網路／區域的閘道或流量必經路徑。檢查對象：經過它轉送的第 3／4 層流量，以及產品支援的更高層內容。
主機型防火牆安裝在單一作業系統上，例如 Linux nftables／ufw 或 Windows Defender Firewall。只要封包最後要交給這台主機，它就能依本機介面、位址、協定與連接埠限制流量。部分主機防火牆還能使用使用者或控制群組（cgroup）等本機資訊。
它可以補足同 VLAN 流量不經 OPNsense 的盲點，同時也會增加分散管理的成本。假設有 100 台 VM，每台都以人工方式配置防火牆，修改規則與追查差異會非常麻煩。因此大量主機還需要搭配版本控制、自動化部署、集中管理與清楚的規則擁有者。
圖（五）主機防火牆檢查送往本機的同 VLAN 流量
部署位置：單一實體主機或 VM 的作業系統內。檢查對象：送往本機或由本機發出的流量。
PVE 防火牆位於資料中心（Datacenter）、節點（Node）或 VM／容器（Container）的虛擬網路層，可在封包抵達 Guest OS 以前限制宿主管理面或特定虛擬網卡（Virtual NIC）。
PVE 防火牆能在虛擬交換層增加一道限制。若同 VLAN VM 的流量會經過 PVE 橋接器，PVE 防火牆便能成為 OPNsense 以外的補償控制。跨 VLAN 路由（Inter-VLAN Routing）則由 OPNsense 負責。
圖（六）資料中心層的 PVE 防火牆設定位置
圖（七）VM 層的 PVE 防火牆設定位置
圖（六）、圖（七）為後續環境補拍，用來示範 PVE 防火牆的設定位置。
需要集中保護 PVE 宿主機、限制特定 VM vNIC，或在 Guest OS 以外增加一道控制時，可以啟用 PVE 防火牆。啟用前要先確認 PVE 8006、SSH、Corosync 等必要流量可以通過。本系列的跨 VLAN 流量由 OPNsense 管理，本機入口則由 Debian 主機防火牆收緊，因此本日只盤點 PVE 防火牆的位置與現況，核心規則路徑由 OPNsense 與主機防火牆負責。
部署位置：虛擬化平台的資料中心、節點、虛擬交換器（Virtual Switch）或 VM vNIC。檢查對象：宿主管理面與通過虛擬網路層的 Guest OS 流量。
虛擬防火牆描述的是交付形式：防火牆本身是一台 VM，執行在 PVE／KVM、VMware ESXi、Hyper-V 或公有雲的虛擬化平台上。它會配置多張虛擬網卡，連接不同的虛擬交換器、橋接器、VLAN 或雲端網路（Cloud Network），再替這些網路執行路由、NAT、VPN 與防火牆政策。
本系列的 OPNsense 就是虛擬防火牆。它以 OPNsense VM 執行在 L0 PVE，WAN vNIC 接到上游網路，內部 vNIC 則接到承載各 VLAN 的橋接器。
部署位置：以 VM 形式執行在虛擬化平台或公有雲平台。檢查對象：從它不同虛擬網卡之間通過的流量。
專用設備就是一般所稱的硬體防火牆（Hardware Firewall）。廠商把防火牆作業系統、CPU、網路卡（NIC）、儲存設備（Storage）、機殼與技術支援整合成一台設備，常見形式包含桌上型設備與機架式設備。
專用設備通常具有清楚的實體介面對應、經過驗證的驅動與較可預測的封包處理能力，也能把網路邊界與 PVE 故障域分開。專用設備本質上也是一套執行防火牆作業系統的電腦，因此同樣需要修補（Patch）、設定備份（Config Backup）、憑證（Certificate）管理、硬體備品與 HA 設計。狀態式過濾、IDS／IPS 或 NGFW 等能力需依實際型號與授權確認。
部署位置：以獨立實體設備接在 WAN、LAN、DMZ 或其他網路區域之間。檢查對象：從實體 NIC 通過設備的流量。
前面依檢查能力與部署位置分類，但還有第三個問題：封包要以什麼方式通過防火牆？路由模式（Routed Mode）會把防火牆放在不同的第 3 層網路之間，由防火牆擔任預設閘道（Default Gateway），並視需求執行路由、NAT 與防火牆政策。本系列的 OPNsense 採用路由模式，各 VLAN 的閘道都位於 OPNsense。
橋接模式（Bridge Mode）或透明防火牆（Transparent Firewall）則把兩張以上的介面加入同一個第二層橋接器。兩側可以繼續使用原本的子網與預設閘道，不必為了插入防火牆重新編址。但實際訊框（Frame）必須穿過這座橋接器，防火牆才能檢查或阻擋。
橋接模式可以和前面的分類交叉組合，不只屬於某一種網路防火牆：
這些名稱其實在回答不同問題：
| 分類問題 | 常見名稱 |
|---|---|
| 用什麼形式交付？ | 虛擬防火牆、專用設備 |
| 能檢查到多深？ | NGFW、WAF、IDS／IPS |
| 部署在哪裡？ | 網路、主機、虛擬化平台防火牆 |
| 流量怎麼通過？ | 路由模式、橋接模式 |
同一套防火牆可以同時具有多個名稱。本系列的 OPNsense 是虛擬防火牆與網路防火牆，並採用路由模式。如果改成未編號的橋接器，只有流量通過方式會變成橋接模式。
前一天有提到 DMZ，這裡再複習一次。網路安全隔離區（Demilitarized Zone，DMZ）位於不同信任區域之間，用來承載可能被較低信任來源接觸的服務。它的目的，是讓外部入口即使遭入侵，也不能直接取得內部高價值資源的完整路徑。
圖（八）同一台 OPNsense 分別檢查 DMZ 的兩個跨區邊界
圖中的兩個 OPNsense 圖示代表同一台防火牆在不同流量路徑上的檢查位置，不是兩台獨立防火牆。
DMZ 代表一個獨立的安全分區。多台主機位於同一個 DMZ VLAN 時，可以直接透過第 2 層通訊。限制這類橫向移動（Lateral Movement）需要搭配主機防火牆、PVE 防火牆、私有 VLAN（Private VLAN）、交換器連接埠隔離（Switch Port Isolation），或繼續拆分 VLAN。建立 DMZ 與限制 DMZ 內部流量是兩項不同的控制工作。
OPNsense 可以安裝在相容的實體設備，也可以部署成 VM。其維護公司 Deciso 亦提供預載 OPNsense 的實體防火牆。兩種形式使用相同的防火牆觀念，差異主要在資源、故障域與維運方式。
OPNsense VM 的優點包括：
OPNsense VM 的限制包括：
專用設備的優勢通常是介面對應清楚、故障域能與 PVE 分離，且硬體與驅動已針對網路用途整合。代價則是額外設備、電力、備品與支援成本。
OPNsense 還能透過外掛增加 HAProxy、Nginx、DNS 過濾與其他服務。這些功能很實用，但本系列將 Nginx 與 HAProxy 部署在 proxy01、proxy02，主要原因是避免擴大同一個故障域：
縱深防禦（Defense in Depth）會把安全控制分散在網路、虛擬化平台、主機、應用程式與資料層。每一層使用自己能取得的資訊做出判斷，前一層失守時，後續控制可以繼續限制攻擊者能到達的範圍與可執行的操作。
防火牆是其中一部分。Nginx、HAProxy 與 PostgreSQL 雖然不全是防火牆，卻能使用網路層看不到的 HTTP 路徑、後端角色、資料庫角色與物件權限（Object Permission）繼續限制存取，因此也屬於本架構的縱深防禦控制。
| 控制位置 | 能使用的資訊 | 本系列主要責任 |
|---|---|---|
| OPNsense | 區域、IP、協定、連接埠、狀態 | WAN、VPN、NAT 與跨 VLAN 規則 |
| PVE 防火牆 | 資料中心、節點、VM／CT、虛擬網卡 | 保護虛擬化平台與特定 VM 的網路入口 |
| Linux 主機防火牆 | 本機介面、位址、連接埠 | 收緊單一作業系統的最後入口 |
| Nginx | TLS、HTTP 主機名稱、路徑、標頭 | 網站反向代理與應用入口 |
| HAProxy | TCP 後端與 Patroni 角色檢查 | 導向可讀寫或唯讀的 PostgreSQL 節點 |
| PostgreSQL | 用戶端、TLS、資料庫、角色、物件 | 驗證資料庫連線與資料權限 |
例如 OPNsense 先確認代理伺服器到 PostgreSQL 5432 的網路路徑符合政策。HAProxy 再確認節點角色，PostgreSQL 接著驗證 TLS、pg_hba.conf、角色與授權（GRANT）。各層共同縮小可能的影響範圍（Blast Radius）。
網路路徑、監聽服務與必要流量完成盤點後，接著確認 PVE 與 Debian VM 各自具有哪些防火牆功能，以及啟用新規則前的實際狀態。這份基準可以保留設定變更前的比較點，也能避免把服務正在監聽、防火牆已經放行和遠端確實可達混為一談。
今天先保存 PVE 與 Debian VM 的防火牆現況。Day 11 開始安裝 OPNsense，後續再建立預設拒絕規則。完整操作與後續重做跨 VLAN 對照的時機，請參考 GitHub 實作文件：
GitHub 詳細實作文件：Day 10｜防火牆分層與現況基準
以 pve01 為例，依序執行：
pve-firewall status
pvesh get /cluster/firewall/options
iptables-save 2>/dev/null | head -n 40
nft list ruleset 2>/dev/null | head -n 80
圖（九）pve01 的 PVE 防火牆狀態與現有規則。
畫面中的 disabled/running 表示 PVE 防火牆背景服務（Daemon）正在執行，但 PVE 防火牆功能尚未啟用。叢集防火牆選項（Firewall Options）沒有自訂值，iptables 的 INPUT、FORWARD 與 OUTPUT 預設政策都是 ACCEPT，nft list ruleset 也沒有列出規則。這些結果共同保存 pve01 當下的啟用前基準。
這份基準確認了設定變更的起點。啟用預設拒絕前，先允許管理網段連入 TCP 8006 與 22，確保 PVE 網頁管理介面（Web UI）與 SSH 管理路徑可用。
在一台測試 VM 執行：
sudo nft list ruleset
sudo ss -lntup
sudo systemctl status nftables --no-pager
圖（十）Debian 測試 VM 尚未建立 nftables 主機防火牆。
畫面中的 nft: command not found 與 Unit nftables.service could not be found 表示這台測試 VM 尚未安裝 nftables 管理工具與服務。這項結果確認這台 VM 目前尚未建立 nftables 主機防火牆過濾機制。
ss -lntup 則列出 SSH、DNS 與 DHCP 用戶端等目前正在監聽或使用的通訊端，讓管理者知道哪些網路入口需要繼續確認。遠端可達性會在後續由實際來源執行連線測試。
| 證明 | 方法 | 可以得到的結論 |
|---|---|---|
| 證明一：PVE 防火牆基準 | 防火牆狀態、叢集選項、iptables 與 nftables 規則 | pve01 當下尚未由 PVE 防火牆套用自訂過濾政策 |
| 證明二：Debian 主機基準 | nftables 工具、服務狀態與既有通訊端 | 測試 VM 尚未安裝及啟用 nftables，並保留受保護入口的對照基準 |
下一篇是 Day 11｜在 Proxmox VE 安裝 OPNsense：vNIC、WAN／LAN 介面指派與 Console 救援。我們會從 L0 Linux 橋接器、VM vNIC、FreeBSD vtnet 裝置到 OPNsense 介面逐層對照，實際安裝 fw01，並保留不依賴 OPNsense 網路設定的主控台救援路徑。
iThome鐵人賽
看影片追技術