前兩篇已經完成跳板機、Linux 路由切換、ProxyJump 與多人權限隔離，讓管理者可以透過 SSH 進入受控的主機管理路徑。不過，遠端使用者不一定需要登入主機。他可能只需要開啟 PVE 網頁管理介面（Web UI）、監控平台，或連接特定的私有服務。若把這些服務逐一公開，防火牆會出現更多對外入口，服務本身也必須各自承擔公開網路的掃描與驗證壓力。

虛擬私人網路（Virtual Private Network，VPN）會先在遠端裝置與組織網路之間建立加密的 Tunnel，再讓授權流量沿著 Tunnel 進入私有網段。本篇使用 OpenVPN 建立 Road Warrior，從外層封包、Tunnel、路由、DNS 到防火牆政策逐步說明，最後才回到 Lab 完成實際部署。

今天要解決的問題

OpenVPN 顯示已連線，只能證明用戶端與 VPN 伺服器已經完成連線，無法直接證明私有服務可以使用。完整路徑還包含身分驗證、Tunnel IP、用戶端路由、名稱解析、防火牆規則與目標服務。

本篇會依序回答以下問題：

• 跳板機與 VPN 分別適合承接哪些遠端需求？
• 外層 OpenVPN 封包如何抵達防火牆，內層服務封包又如何進入私有網路？
• 控制通道與資料通道各自負責什麼？
• CA、伺服器憑證、用戶端憑證、帳號與選用的 OTP 如何共同確認身分？
• Split Tunnel、Full Tunnel、路由與 DNS 如何影響用戶端？
• 使用者通過 VPN 驗證後，如何繼續依群組限制可存取的服務？
• 連線失敗時，應該按照什麼順序定位問題？

本文閱讀方式

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

⭐ 跳板機與 VPN 解決不同的遠端需求

跳板機與 VPN 都能減少直接公開的內部服務，但它們提供的能力不同。

使用 VPN 不代表遠端裝置成為完全可信任的內部主機。VPN 只建立一條可被路由與過濾的 Tunnel，真正能抵達哪些服務，應該先由防火牆依身分群組、目的地與連接埠決定。

⭐ 先分清楚外層連線與內層封包

OpenVPN Road Warrior 會同時處理兩種不同視角的封包：

遠端裝置存取私有網頁管理介面時，封包依序經過以下路徑：

圖（一）遠端用戶端先將內層 IP 封包加密並封裝成外層 UDP 封包。OPNsense 解密後，再依 OpenVPN 規則轉送到私有服務。

WAN 規則只允許外層封包抵達 OpenVPN 監聽端點。封包完成解密後，防火牆看到的是 Tunnel IP 到私有服務的內層流量，還要再次通過 OpenVPN 介面的過濾規則。這兩組規則保護的位置不同。

OpenVPN 的加密範圍到 VPN 端點為止。OPNsense 解密外層封包後，會把取出的內層 IP 封包繼續路由到目的網段。後面這段是否加密，取決於 HTTPS、PostgreSQL TLS 等應用程式協定。

TUN 與 TAP 虛擬介面

TUN 與 TAP 都是由作業系統建立的虛擬網路介面。前面介紹 PVE 虛擬網路時已經看過兩者的基本差異：TUN 在第三層網路層工作，收送 IP 封包。TAP 在第二層資料連結層工作，收送包含 MAC 位址的乙太網路訊框。

在 PVE 中，TAP 是 VM 虛擬網卡位於宿主機端的出口，並連接 Linux Bridge。到了 OpenVPN，TUN 或 TAP 則成為 OpenVPN 與作業系統交換內層流量的介面。選擇其中哪一種，會決定 VPN 延伸的是可路由的 IP 網路，還是整個乙太網路。

本系列的 Road Warrior 使用 TUN。用戶端取得獨立的 Tunnel IP，再依伺服器提供的路由存取私有網段。VPN 只需要攜帶第三層 IP 封包，不必把遠端裝置接進內部乙太網路。

外層傳輸使用 UDP 或 TCP

OpenVPN 可以使用 UDP 或 TCP 建立外層連線，這項選擇不會改變 Tunnel 內原有的應用程式協定。UDP 不會在外層再次處理排序與重傳，通常較適合承載 VPN。若改用 TCP，Tunnel 內的 TCP 與外層 TCP 可能同時重傳並調整傳輸速度。TCP 主要用於所在網路封鎖 UDP 的相容情境。

本系列使用 UDP 1194。Tunnel 內的 HTTPS、SSH 或 PostgreSQL 即使使用 TCP，依然是由各自的內層 TCP 處理可靠傳輸。

OpenVPN 協定內部的控制通道與資料通道

上一節說明的是外層封包使用 UDP 或 TCP 傳輸。進入 OpenVPN 協定內部後，還會再區分控制通道（Control Channel）與資料通道（Data Channel）。這兩條邏輯通道共用同一個外層 UDP 或 TCP 監聽端點，再由控制通道處理連線建立，由資料通道承載加密後的內層服務封包。

控制通道

控制通道負責建立與維護連線，包括：

• 驗證伺服器憑證與用戶端憑證。
• 執行帳號、密碼與已啟用的 OTP 驗證。
• 協商資料通道使用的加密參數與 Session Key。
• 傳送 Tunnel IP、路由與 DNS 等連線設定。
• 在連線期間重新協商金鑰。

資料通道

資料通道使用控制通道協商出的暫時金鑰，處理實際通過 VPN 的 IP 封包，包括：

• 從 TUN 虛擬介面讀取準備送入 Tunnel 的內層 IP 封包。
• 使用 Session Key 加密並驗證內層封包，再封裝成外層 UDP 封包送出。
• 收到外層封包後驗證並解密，再將取出的內層 IP 封包交回虛擬介面與作業系統網路堆疊。
• 承載網頁、資料庫與其他私有服務的實際流量，不負責帳號驗證、路由或 DNS 設定。

控制通道與資料通道共用監聽端點，不代表它們使用同一把長期金鑰持續加密所有資料。OpenVPN 會讓資料通道使用另外協商的暫時金鑰，並可在連線期間輪替。

本次設定使用現代的資料通道加密演算法（Data Cipher），並停用壓縮（Compression）。OpenVPN 2.6 手冊已將壓縮列為不建議使用的相容性功能。壓縮加密前的資料還可能增加額外的攻擊面，沒有明確需求時不應重新開啟。

⭐ 建立 Tunnel 前先確認雙方身分

遠端存取 VPN 會把外部裝置帶到私有網路邊界，因此連線建立前必須確認伺服器與使用者。遠端 VPN、多因素驗證、個別帳號、最小權限與紀錄是相互配合的防護措施。

憑證可以先理解成一份能由系統查驗的身分證明，憑證授權中心（Certificate Authority，CA）則負責簽發這些證明。只要 OpenVPN 兩端信任同一個 CA，就能檢查對方提出的憑證是否由受信任的 CA 簽發，以及對方是否持有與憑證相對應的私鑰。

OpenVPN 驗證會由以下元件共同完成：

各元件使用的憑證與金鑰必須分開保存：

HMAC 讓接收端確認封包由持有相同共享金鑰的一方送出，而且內容在傳輸途中沒有遭到修改。它在這裡負責驗證控制通道封包，不負責加密封包內容。

每張伺服器或用戶端憑證各自對應不同的私鑰。TLS 靜態金鑰則由所有獲准的用戶端共用，因此不能拿來代表個別使用者身分。帳號與已啟用的 OTP 會再確認目前登入的使用者。

OTP 不是建立 OpenVPN Tunnel 的必要條件。沒有啟用 OTP 時，還是可以使用用戶端憑證、使用者名稱與密碼完成驗證。若 VPN 直接公開在網際網路，尤其允許管理重要系統時，建議再加入 OTP 或其他多因素驗證，降低密碼外洩後被直接登入的風險。

OPNsense 的本機資料庫（Local Database）驗證可以啟用嚴格比對使用者與 CN（Strict User/CN Matching），要求用戶端憑證的通用名稱（Common Name，CN）與登入使用者名稱相同。搭配每位使用者各自的憑證，系統才能把連線、帳號、憑證與後續群組政策對應在一起。

這裡先理解 CA 與各種憑證在 OpenVPN 連線中的用途。公鑰、私鑰、數位簽章、信任鏈、憑證用途與生命週期，會在後續建立內部 CA 時完整說明。

從第一個封包到資料通道

前面的驗證材料會依序參與連線建立。本次使用 auth 模式的 TLS Static Key。用戶端必須先持有這把共享金鑰，伺服器才會繼續處理後面的 TLS 與使用者驗證。它可以在較早階段丟棄不具有效 HMAC 的控制通道封包，但無法辨識個別使用者，也不能取代用戶端憑證。

圖（二）OpenVPN 依序完成外層連線、控制通道驗證、使用者驗證與參數協商，最後才開始傳輸內層 IP 封包。

其中一項檢查失敗，連線就不會進入後續階段。UDP 1194 可以連通只證明外層路徑可達，不能證明憑證、登入、路由與服務存取都已成功。

⭐ Tunnel IP 與路由決定封包往哪裡走

驗證完成後，OpenVPN 會為用戶端建立虛擬介面並配發 Tunnel IP。這個位址代表用戶端在 VPN 內的來源位置，防火牆也會以它識別解封裝後的流量。

伺服器還需要告訴用戶端哪些目的網段應交給 VPN。這些路由會加入用戶端路由表。當封包的目的地符合其中一條路由時，作業系統才會把它送入 OpenVPN 虛擬介面。

Tunnel Network、私有網段與用戶端目前所在的本地網段不能互相重疊。若兩端同時使用相同前綴，用戶端的直接連線路由可能與 VPN 路由衝突，作業系統無法只靠目的地判斷封包應送往本地網路或 VPN Tunnel。

圖（三）目的位址符合 VPN 路由時送入 OpenVPN。其他流量沿用原本的預設路由。

回程封包如何返回 VPN 端點

私有服務收到連線後，會把回覆送往封包的來源位址。VPN 端點如何轉送封包，會決定服務主機看到的是用戶端的 Tunnel IP，還是 VPN 端點的內部 IP。在路由模式（Routed Mode）中，VPN 端點解密內層封包時會保留用戶端的 Tunnel IP，因此私有服務回覆的目的地也是這個 Tunnel IP。內部路由若不知道 Tunnel Network 應該交給哪個 VPN 端點，就會把回覆送往錯誤的閘道，形成去程可以抵達、回程卻消失的非對稱路徑。

VPN 常用以下兩種方式處理回程：

本系列由 OPNsense 同時擔任 OpenVPN 端點、內部網段閘道與防火牆。私有服務原本就把 OPNsense 設為預設閘道，而 OPNsense 也持有通往 Tunnel Network 的路由，因此不需要額外設定 SNAT 或另一條回程路由。

圖（四）路由模式與 SNAT 會讓私有服務看到不同的來源位址，也會形成不同的回程條件。

若 OpenVPN 端點與內部閘道分開部署，就要在內部路由器建立一條前往 Tunnel Network、下一跳指向 VPN 端點的路由。SNAT 則是替代方案。在 OPNsense 中會透過 Outbound NAT 規則設定，但不屬於後面的 Lab 實作內容。

Split Tunnel

Split Tunnel 只把指定的組織網段送入 VPN，其他網際網路流量繼續使用用戶端原有的預設路由。

它能減少 VPN 閘道的頻寬負擔，也不會讓所有一般上網流量繞回組織網路。代價是遠端裝置同時連接外部網路與私有網路。若裝置遭入侵，可能成為兩個網路之間的攻擊跳板。因此 Split Tunnel 要搭配端點防護、最小權限與紀錄。

Full Tunnel

Full Tunnel 會把預設路由導向 VPN，讓一般網際網路流量也先回到組織的 VPN 閘道。這能集中套用出口政策與監看，但會增加閘道的頻寬、效能與可用性負擔。

若 OpenVPN 伺服器將所有用戶端的網際網路流量帶回內部，防火牆還必須具備對應的出站 NAT（Outbound NAT）與出口規則。只推送預設路由，沒有出口轉送能力，用戶端可能在連上 VPN 後失去網際網路連線。

簡單來說，Split Tunnel 只接管指定的私有網路流量，一般上網流量同樣走用戶端原本的網路。Full Tunnel 則會接管用戶端的大部分對外流量，連一般上網流量也會先進入 VPN，再從 VPN 閘道送往網際網路。

以下使用相同的私有目的地與公開目的地比較兩種模式：

圖（五）Split Tunnel 只將符合指定私有網段的流量送入 VPN，一般上網流量維持原有路徑。

圖（六）Full Tunnel 將兩類流量都送入 VPN。一般上網流量經 VPN 閘道執行 Outbound NAT 後，再送往網際網路。

本系列只把 10.77.10.0/24 與 10.77.20.0/24 送入 VPN Tunnel，採用 Split Tunnel。一般網際網路流量維持原本路徑。

DNS 讓私有服務名稱沿著正確路徑解析

路由決定封包往哪裡送，DNS 則將名稱解析為 IP。若使用者要透過 pve01.lab.home 存取私有服務，OpenVPN 可以向用戶端提供：

• 內部 DNS 伺服器位址。
• 內部 DNS 網域（Domain）或搜尋網域（Search Domain）。
• 可抵達 DNS 伺服器的路由。

DNS 伺服器還必須真的存在對應紀錄，防火牆也要允許 Tunnel Network 查詢 DNS。只設定網域尾碼（Domain Suffix），不會自動建立 pve01.lab.home。只推送 DNS 伺服器，卻沒有路由或防火牆規則，也無法完成解析。

⭐ 通過 VPN 驗證後要套用最小權限

VPN 驗證決定誰可以建立 Tunnel，防火牆規則則限制每個身分可以使用哪些服務。若直接允許 OpenVPN 網路連向任意目的地，所有成功登入的使用者都可能接近相同的內部網段，帳號群組便失去區隔用途。

OPNsense 的 OpenVPN 群組別名（OpenVPN Group Alias）能把目前登入使用者的 Tunnel IP，依系統存取群組（System Access Group）動態加入別名。防火牆便能用群組身分建立規則，不必假設某位使用者永遠取得固定 Tunnel IP。

這項對應需要滿足兩個條件：

1. OpenVPN 登入使用者已加入對應的 OPNsense 群組。
2. 憑證的通用名稱與使用者名稱相同，讓連線狀態（Connection Status）能正確識別使用者。

規則順序決定結果

OPNsense 依介面上的規則順序由上往下比對，因此特定允許規則必須位於一般封鎖規則之前：

1. VPN 管理群組 → PVE 8006    允許
2. OpenVPN 網路 → PVE         封鎖
3. OpenVPN 網路 → PG 節點     封鎖
4. 其餘流量                   預設拒絕

若把 PVE 封鎖規則放在管理群組允許規則前面，管理帳號也會先命中封鎖規則。規則內容正確，順序錯誤，最終結果還是會失敗。

撤銷憑證與中止現有 Session

當裝置遺失、使用者離職或用戶端設定檔外洩時，管理者需要讓該憑證失效。撤銷用戶端憑證後，新連線應被拒絕。既有 Session 是否立即消失，取決於 OpenVPN 伺服器是否重新載入撤銷資訊，以及管理者是否主動中止目前連線。

完整撤銷流程應包含：

1. 撤銷指定的用戶端憑證。
2. 確認 OpenVPN 伺服器已載入最新撤銷狀態。
3. 中止該使用者仍存在的 Session。
4. 驗證原設定檔無法重新連線。
5. 保留撤銷原因與操作紀錄。

只刪除本機上的設定檔，不會使已複製到其他位置的設定檔失效。只停用帳號，也不能取代憑證的生命週期管理。

問題排查方式

VPN 問題適合沿著封包實際經過的順序檢查。跳過前面的條件直接調整後端服務，往往只會增加變數。

可以搭配 OPNsense 的 OpenVPN 連線狀態（Connection Status）、OpenVPN 紀錄、防火牆即時檢視（Firewall Live View）與封包擷取（Packet Capture），分別確認 Session、驗證、規則比對與封包回程。

本次實驗：驗證 OpenVPN Road Warrior 與最小權限

本次在 OPNsense 建立 OpenVPN Road Warrior，使用本機資料庫與每位使用者各自的用戶端憑證，並可依需求加入 OTP。驗證不會停在用戶端顯示已連線，而會繼續檢查 Tunnel IP、Split Tunnel 路由、內部 DNS、群組防火牆規則與憑證撤銷。

GitHub 實作文件：Day 17｜OpenVPN 遠端存取

部署摘要

驗證一：個別帳號、憑證與群組形成可撤銷身分

先到 System → Firmware → Packages 確認 OpenVPN 已安裝，再進入 VPN → OpenVPN，確認選單內有 Instances、Client Export、Connection Status 與 Log File。本系列使用內建功能，不安裝舊版 os-openvpn-legacy Plugin。

到 System → Trust → Authorities 按 Add，建立內部 CA IRON-LAB-OPENVPN-CA。接著進入 System → Trust → Certificates 按 Add，建立由該 CA 簽發、Common Name 為 vpn.lab.home 的 Server Certificate。

圖（七）在 Authorities 建立自簽的 OpenVPN CA，設定 RSA-3072、SHA256 與 Common Name。

再到 System → Access → Users，建立四個用途不同的測試帳號：

vpn-rw01
vpn-ro01
vpn-monitor01
vpn-admin01

圖（八）四種用途各自使用獨立的 OPNsense 本機帳號。

建立帳號後，在 System → Access → Users 編輯個別使用者，於 Certificates 區域按 Add。Method 選 Create an internal Certificate、Type 選 Client Certificate、Issuer 選 IRON-LAB-OPENVPN-CA，Common Name 則與 Username 保持相同。每個帳號各自建立一張 Client Certificate，不共用憑證與私鑰，後面才能使用 Strict User/CN Matching 將登入帳號、憑證與群組授權正確對應。

圖（九）vpn-admin01 的用戶端憑證具有 clientAuth 用途，Issuer 與 Common Name 均符合規劃。

到 System → Access → Groups 建立本機群組 vpn-admin，目前只加入 vpn-admin01。其餘帳號先完成獨立身分，資料庫與監控服務的權限會等對應入口完成後再加入。

圖（十）vpn-admin 群組目前只包含 vpn-admin01，供動態 OpenVPN Group Alias 對應。

驗證二：Server Instance 建立 TUN 與 Split Tunnel

先進入 VPN → OpenVPN → Instances → Static Keys，依序完成：

1. 按 Add。
2. Mode 選 auth。
3. Description 填 IRON-LAB-OPENVPN-TLS-AUTH。
4. 按 Key 欄位旁的 Generate 按鈕產生 TLS Static Key。
5. 按 Save 與 Apply，回到 Static Keys 清單確認這把金鑰已出現。

圖（十一）TLS Static Key 使用 auth 模式。按下 Generate 後才會產生用來驗證控制通道封包的共享金鑰。

接著進入 VPN → OpenVPN → Instances，按 Add 建立 Server Instance。Role 選 Server，Description 填 IRON-LAB-ROAD-WARRIOR，其餘關鍵欄位如下：

按 Save 與 Apply 後回到 VPN → OpenVPN → Instances，確認 IRON-LAB-ROAD-WARRIOR 已啟用，而且 Type 為 TUN。資料通道沿用現代加密演算法，不啟用 Compression。用戶端連線後，再到 VPN → OpenVPN → Connection Status 確認實際 Session。

圖（十二）OpenVPN Instances 清單顯示 IRON-LAB-ROAD-WARRIOR 已啟用並使用 TUN。

驗證三：WAN 與 OpenVPN 規則分開控制外層及內層流量

進入 Firewall → Rules，按 Add 並將 Interface 選為 WAN。這條規則只允許外層連線抵達 VPN Server：

WAN：any → WAN address UDP 1194　Pass + Log

接著到 Firewall → Aliases 按 Add，建立類型為 OpenVPN group 的動態 Alias VPN_ADMIN_CLIENTS，Content 選擇 vpn-admin。當 vpn-admin01 登入後，它取得的 Tunnel IP 才會自動加入這個 Alias。

再回到 Firewall → Rules，按 Add 並將 Interface 選為 OpenVPN。依序建立以下規則：

1. OpenVPN network → This Firewall TCP／UDP 53       Pass
2. VPN_ADMIN_CLIENTS → PVE_NODES TCP 8006           Pass + Log
3. OpenVPN network → PVE_NODES any                  Block + Log
4. OpenVPN network → PG_NODES any                   Block + Log
5. 其餘流量                                          隱含 Default Deny

圖（十三）OpenVPN Group 規則先允許 DNS 與 vpn-admin 存取 PVE TCP 8006，再封鎖其他 PVE 與 PostgreSQL 節點流量。

第二條必須位於第三條之前，管理帳號才能使用 PVE Web UI。即使是 vpn-admin01，連接 PVE SSH 22 仍會被第三條規則拒絕。所有 VPN 使用者也不能繞過資料庫 VIP 直接連接 pg01～pg03。

驗證四：Tunnel IP、路由與 DNS 符合 Split Tunnel 設計

到 VPN → OpenVPN → Client Export，將 Remote Access Server 選為 IRON-LAB-ROAD-WARRIOR，再為每位使用者匯出內嵌 CA、個人憑證、個人私鑰與 TLS Static Key 的設定檔。這些檔案包含私鑰，必須透過受控方式交付，不能放入 Git Repository 或公開截圖。

從外部網路使用 vpn-admin01 連線後，在 Windows PowerShell 檢查 Tunnel IP、路由與 DNS：

ipconfig
route print
Resolve-DnsName pve01.lab.home -Server 10.77.10.1

路由表應只新增 10.77.10.0/24 與 10.77.20.0/24 的 VPN 路由，原本的 Default Route 不變。DNS 查詢應將 pve01.lab.home 解析為 10.77.10.11。

圖（十四）用戶端取得 10.77.60.2，只有 10.77.10.0/24 與 10.77.20.0/24 經 OpenVPN。預設路由依然指向原有網路，內部 DNS 也能解析 pve01.lab.home。

驗證五：管理群組只取得 PVE Web UI 權限

接著驗證權限邊界：

Test-NetConnection 10.77.10.11 -Port 8006
Test-NetConnection 10.77.10.12 -Port 8006
Test-NetConnection 10.77.10.13 -Port 8006
Test-NetConnection 10.77.10.11 -Port 22
Test-NetConnection 10.77.30.11 -Port 5432

前三項應成功，PVE SSH 22 應由 OpenVPN 規則拒絕。10.77.30.0/24 沒有列入本次推送路由，因此 PostgreSQL 測試應沿用用戶端原有的網路路徑，而不是經過 VPN。再改用 vpn-ro01 或 vpn-monitor01 連線，PVE TCP 8006 也必須失敗。測試時同時查看 OpenVPN Connection Status 與 Firewall Live View，確認使用者取得 Tunnel IP，而且經過 VPN 的成功與拒絕流量命中預期規則。

圖（十五）vpn-admin01 經 OpenVPN 連接三台 PVE 的 TCP 8006 成功，直接連接 PVE SSH 22 則失敗。

圖（十五）的 PostgreSQL 測試來源為 192.168.0.16，不是 10.77.60.x。這表示 10.77.30.0/24 沒有被 Split Tunnel 送入 OpenVPN，因此只能驗證用戶端未取得資料庫網段的 VPN 路由，不能用來宣稱命中 BLOCK_OPENVPN_TO_PG_NODES。該 Block Rule 保留為額外防線。還要改用一般使用者設定檔測試 PVE TCP 8006，才能驗證 VPN_ADMIN_CLIENTS 與後方 Block Rule 的群組差異。

圖（十六）一般使用者取得 10.77.60.6，流量確實由 OpenVPN 介面送出，但無法連接 PVE TCP 8006。

圖（十三）建立規則時尚未啟用封包紀錄，因此第一次測試只能確認連線失敗。替 BLOCK_OTHER_OPENVPN_TO_PVE_NODES 啟用 Log 並重新測試後，Firewall Live View 才能指出實際命中的規則。

圖（十七）來源 10.77.60.6 連接 10.77.10.11:8006 時，命中 BLOCK_OTHER_OPENVPN_TO_PVE_NODES 並由 OPNsense 阻擋。

驗證六：撤銷憑證並中止既有 Session

最後停用 vpn-ro01、撤銷它的 Client Certificate 並更新撤銷清單，再從 Connection Status 中止既有 Session。帳號停用與憑證撤銷是兩道獨立控制：前者阻止該帳號通過使用者驗證，後者則讓已簽發的憑證失效。原本匯出的設定檔應無法重新建立連線。

圖（十八）vpn-ro01 的用戶端憑證已加入撤銷清單，撤銷類型為 Cessation of Operation。

圖（十九）OPNsense 紀錄顯示 vpn-ro01 無法通過使用者驗證，用戶端也收到 AUTH_FAILED，確認停用帳號後舊設定檔無法重新登入。

Lab 驗證對照

今天完成了什麼

• 建立個別 VPN 帳號、用戶端憑證與 vpn-admin 群組，保留獨立授權及撤銷邊界。
• 建立使用 TUN、UDP 1194 與 10.77.60.0/24 的 OpenVPN Road Warrior。
• 以 Split Tunnel 推送管理與服務網段路由，並提供內部 DNS 設定。
• 分別使用 WAN 與 OpenVPN 規則控制外層連線及解封裝後的內層流量。
• 以管理帳號、一般帳號與撤銷後的舊設定檔執行正向、負向及撤銷測試。

下一篇預告

下一篇將進入 OPNsense IDS／IPS，從封包擷取、流量（Flow）、Session、應用層辨識與規則比對（Rule Match）開始，說明 Suricata 如何產生警示（Alert）或丟棄（Drop），以及加密流量、效能與誤判會如何限制偵測結果。

參考資料

• OPNsense Documentation：Setup SSL VPN Road Warrior
• OPNsense Documentation：OpenVPN Group Alias
• OPNsense Documentation：OpenVPN Troubleshooting
• OpenVPN 2.6 Manual
• OpenVPN Documentation：Understanding TCP Meltdown
• NIST SP 800-113：Guide to SSL VPNs
• 數位發展部資通安全署：中小企業基本資安防護指引