WAN 介面顯示一個 IPv4 位址，只代表接取流程完成了其中一部分。完整的上網路徑還包含實體連線、上游設備、接取與取址方式、預設閘道、路由表、名稱解析與來源位址轉換。
建立 WAN 前要分開回答三個問題：WAN 端設備透過 PPPoE、DHCP，還是手動輸入參數完成接取與取址？ISP 配發的 IPv4 是浮動還是固定？公網 IPv4 最後是配置在 OPNsense 的 WAN，還是配置在 OPNsense 前方的 ISP 設備或既有路由器？三個答案共同決定 WAN 設定、NAT 次數與排錯順序。
外部使用者要連回這個網路，必須先知道可由 Internet 到達的公網 IPv4，或使用能解析成該位址的 DNS 名稱。固定公網 IPv4 可以建立一般 DNS 紀錄。浮動公網 IPv4 改變時，則可由 DDNS 更新名稱指向。
本篇先辨認 ISP 可能交付的 WAN 方案，再畫出各方案的實際鏈路，接著依照 WAN 的建立順序完成 IPv4 Internet 路徑。內部 VLAN 與安全區域、詳細防火牆規則、目的位址轉換及公開服務，分別留給後續章節實作。
本文閱讀方式
- 完整理解技術與底層原理：依序閱讀全文。
- 掌握完成部署所需的基本概念：優先閱讀標有「⭐」的章節。
- 快速了解當天的部署內容：閱讀文末的 Lab／實作章節。
- 跟著系列建立完整系統：依照 GitHub 詳細部署文件 的天數順序操作。
公網 IPv4 能在 Internet 上被路由，位址必須由 ISP 或位址管理機構分配，不能由使用者任意挑選。RFC 1918 定義了供組織或家庭內部使用的私有 IPv4。這些位址不會直接出現在 Internet 的全域路由中，而且不同網路可以重複使用相同的私有位址。
| RFC 1918 私有網段 | 位址範圍 |
|---|---|
10.0.0.0/8 |
10.0.0.0～10.255.255.255 |
172.16.0.0/12 |
172.16.0.0～172.31.255.255 |
192.168.0.0/16 |
192.168.0.0～192.168.255.255 |
內部主機使用私有 IPv4 時，通常要經過 NAT 才能共用公網 IPv4 對外連線。外部流量必須同時具備正確的路由、NAT、防火牆規則與可用服務，才能進入內部系統。
如何取得 WAN 參數與取得的 IPv4 會不會改變是兩個不同問題。先看接取與取址方式：
| 接取與取址方式 | WAN 端設備如何取得參數 | ISP 應提供的資料 |
|---|---|---|
| PPPoE | 以帳號與密碼建立工作階段，再由 ISP 協商 IPv4 參數 | PPPoE 帳密。必要時另提供 Service Name 等條件 |
| DHCP | 向 ISP 或上游設備要求租約，自動取得位址、前綴、閘道與 DNS | 是否限制 MAC 位址或主機名稱（Hostname） |
| 手動靜態設定 | 管理者依 ISP 文件輸入位址、前綴與閘道 | 完整的位址、前綴、閘道、DNS 與交付方式 |
再看 IPv4 位址是否穩定：
| 位址特性 | 意義 | 可能搭配的取址方式 |
|---|---|---|
| 浮動 IPv4 | 重新連線、租約更新或 ISP 調整後，位址可能改變 | PPPoE 或 DHCP |
| 固定 IPv4 | ISP 讓同一條線路、帳號或客戶持續取得指定的位址 | PPPoE、DHCP 或手動靜態設定 |
固定 IP 描述位址穩定性。PPPoE、DHCP 與手動靜態設定則描述接取與取址方式。ISP 可以透過這三種方式交付固定公網 IPv4。
WAN 端設備照常以 PPPoE 連線或透過 DHCP 取址，ISP 再依帳號、線路或設備資料辨認客戶，每次配發相同的公網 IPv4。使用者通常不必在 WAN 手動輸入這個位址。
圖（一）ISP 依帳號、線路或設備資料配發固定公網 IPv4
ISP 提供固定的公網位址、前綴（網路位址加遮罩長度）與閘道，使用者依文件把參數填入 WAN。WAN 位址與 ISP 閘道位於同一個網段，因此 WAN 可以直接把封包交給該閘道。
圖（二）WAN 與 ISP 閘道位於同一個固定公網網段
簡單來說，ISP 劃分一個公網網段給客戶使用，並將通往這個網段的封包路由到客戶路由器。客戶路由器要先透過 PPPoE 或另一條 WAN 連線接上 ISP，再把其中一個可用位址設定在下游介面作為預設閘道，其餘位址才能配置給後方的公開服務。
圖（三）ISP 經由傳輸網段交付額外路由公網前綴
圖中有兩個用途不同的網段：198.51.100.0/30 負責連接 ISP 與客戶路由器，客戶 WAN 使用 198.51.100.2/30，預設閘道為 198.51.100.1。ISP 再把 203.0.113.8/29 路由到客戶 WAN。
圖中的 198.51.100.0/24 與 203.0.113.0/24 均為 RFC 5737 保留的文件範例位址，不代表任何實際 ISP 配發結果。
203.0.113.9/29 是客戶路由器直接連接下游網段的介面，本身不需要另一個預設閘道。它就是下層服務使用的預設閘道。
在這個 /29 範例中，客戶路由器的下游介面使用 203.0.113.9/29，並作為下層服務的預設閘道。服務可使用 203.0.113.10 至 203.0.113.14。203.0.113.8 是網路位址，203.0.113.15 是廣播位址，兩者不能配置給設備。
三者的判斷方式很直接：PPPoE 或 DHCP 固定位址由 ISP 自動配發。同鏈路固定網段的 WAN 與 ISP 閘道位於同一個網段。額外路由公網網段則先建立 WAN 連線，再由 ISP 把另一個公網網段路由到客戶路由器。判斷交付方式應以取址流程與路由關係為主，位址數量作為輔助資訊。
台灣 HiNet 非固定制光世代通常使用 PPPoE。遠傳 Seednet 的部分網內光纖，以及凱擘等有線電視寬頻，則以 DHCP 自動配發位址。兩種接取方式都可能再搭配浮動或固定 IPv4。
HiNet 方案常見選項是 8 個動態 IP，或 7 個動態 IP 加 1 個 PPPoE 固定 IP。使用不同 PPPoE 帳號會取得對應類型的位址。企業固定制還可能提供 2 個、6 個或其他數量的固定 IPv4。
WAN 是路由器或防火牆面向上游網路的邏輯角色，這裡釐清公網 IPv4 最後由哪一台設備持有。
圖（四）上游設備的路由模式與橋接模式
光纖進入住家或企業後，通常會先連到 ISP 提供的設備。真正重要的是它採用哪一種工作模式：
路由模式已經能提供 NAT 與 DHCP，為什麼還會使用橋接模式？一般住家常直接使用 ISP 提供的上游設備完成接取也就是常聽到的小烏龜，他進行 NAT、DHCP 與基本路由，部署簡單，也足以應付多數使用情境。但以我們現在的狀況後方另有 OPNsense 等路由器時，保留上游路由模式會讓 OPNsense WAN 取得私有 IPv4，形成兩層路由與 NAT。改用橋接模式後，接取與公網 IPv4 可以交由 OPNsense 處理，路由、NAT 與防火牆政策也能集中在同一處管理。當然另一方面也有 ISP 提供的設備效能問題。
前方路由器先把公網 IPv4 轉換成第一段私有 IPv4，後方 OPNsense 再轉換成另一段私有 IPv4，就形成雙重 NAT（Double NAT）。一般出站連線通常可以正常使用，但入站通訊埠轉送要在兩台設備分別設定，連線狀態與紀錄也分散在兩處，部分 VPN、語音或點對點應用的排錯會更複雜。
以 WAN 的視角來看，取得 Internet 連線要先建立鏈路、完成接取與取址，再確認公網 IPv4 的位置、預設閘道、路由表與 DNS。內部使用私有 IPv4 時，還要透過來源 NAT（Source NAT）出站。公網 IPv4 會改變，而且需要讓外部使用者持續找到同一個對外名稱時，才需要 DDNS。
下面是我簡單整理的 WAN 連接到網路的過程：
圖（五）WAN 從建立鏈路到維護對外名稱的檢查順序
檢查時依照圖中的順序往下進行。介面顯示 UP 可確認鏈路存在。取得 IPv4 後還要驗證預設路由。Ping 公網 IPv4 可確認對外路徑，DNS 查詢則需另外驗證。外部使用者連入服務時，還要具備後續的通訊埠轉送（Port Forward）、防火牆規則與可用服務。
本篇以 IPv4 為主。IPv6 可能由 DHCPv6、前綴委派（Prefix Delegation）或 PPPoE 配發，安全邊界主要依賴防火牆與前綴設計，不能直接套用 IPv4 的來源 NAT、雙重 NAT 與通訊埠轉送模型。完整的 IPv6 規劃需要另行處理。
圖（六）確認 WAN 鏈路時需要逐段排查的虛擬網路路徑
前面已介紹圖中的 PVE Linux Bridge、TAP、VirtIO 網卡與 OPNsense vtnet0。這裡把圖片作為 WAN 鏈路的排錯範圍：確認 vtnet0 具有 Link，並觀察收送封包計數是否增加。
兩條判斷軸釐清後，再看三種接取與取址方式如何運作。方式由 ISP 或上游設備決定。浮動或固定只描述最後取得的位址是否穩定，不會改變 PPPoE 與 DHCP 本身的運作流程。
PPP（Point-to-Point Protocol）用來建立並管理兩個端點之間的邏輯連線。在固網接取情境中，兩個端點通常是用戶端路由器與 ISP。PPP 主要負責三件事：
IPCP 的基本 IPv4 位址協商由 RFC 1332 定義。DNS 伺服器位址則可透過 RFC 1877 增加的 IPCP 選項提供。
圖（七）PPP 從建立連線到協商 IPv4 參數的流程
PPP 原本適合只有兩個端點的連線，本身沒有在共用乙太網路中尋找 ISP 接取設備與區分不同客戶工作階段的機制。PPPoE（PPP over Ethernet）在 PPP 外面加入乙太網路封裝、探索流程與工作階段識別碼（Session ID），讓多個用戶可以經由乙太網路分別連到 ISP 的接取集中器（Access Concentrator）。
PPPoE 因此先進行探索階段（Discovery Stage），由用戶端找到接取集中器並取得 Session ID。接著進入 PPP 工作階段（PPP Session Stage），完成 LCP、身分驗證與 IPv4 參數協商。
圖（八）PPPoE 探索階段與 Session ID 建立流程
PADI 使用乙太網路廣播，因此用戶端可能收到多台接取集中器送出的 PADO。用戶端依 AC 名稱與提供的服務選擇其中一台，再以 PADR 提出請求。接取集中器接受後，才在 PADS 中指派 Session ID。工作階段建立後，任一端都可以使用 PADT（Terminate）終止該工作階段。
這些階段提供很實用的排錯線索：
一般乙太網路常見 MTU 為 1500 Bytes。傳統 PPPoE 增加 8 Bytes Header，因此常見 IP MTU 為 1492。ISP 與整條乙太網路路徑都支援 RFC 4638 時，PPPoE 才可能維持 1500 Bytes IP MTU。若小型封包正常，但部分 HTTPS 或 VPN 連線卡住，再檢查 MTU。
DHCP 用戶端通常會交換 DHCPDISCOVER、DHCPOFFER、DHCPREQUEST 與 DHCPACK 四種主要訊息，這組流程常縮寫為 DORA。成功的租約可以同時提供：
圖（九）DHCP DORA 租約交換流程
WAN 端設備取得 DHCP 租約後，通常會把租約提供的閘道當成通往其他網路的下一站。位址與可用閘道必須同時存在，WAN 才能連到其他網路。
DHCP 配發浮動或固定 IP 都使用相同的租約流程。固定 DHCP 位址是由 ISP 或 DHCP 伺服器維持配發結果。若前方路由器由自己管理，也可以建立 DHCP 保留位址（Reservation），維持監控、轉送與排錯紀錄使用的位址不變。
路由器的 WAN 取得前述 RFC 1918 私有位址時，代表它沒有直接持有可由 Internet 路由的公網 IPv4。公網位址位於更上游的設備，或由其他上游設備進行位址轉換。判斷公網 IPv4 的持有位置可以比較：
若路由器的 WAN 與外部看到的公網位址相同，路由器通常直接持有公網 IPv4。
若 OPNsense 的 WAN 是私有位址，而前方路由器的 WAN 拿到了公網 IPv4，封包會依序經過 OPNsense 與前方路由器兩次 IPv4 NAT。
圖（十）兩台路由器分別執行一次 NAT 而形成雙重 NAT
這一步的重點是找出 NAT 實際發生在哪些設備。雙重 NAT 對入站轉送、紀錄與排錯的影響，已在前面的 WAN 路徑說明。
WAN 位址與公網位置確認後，還要分開驗證三項狀態：
預設閘道（Default Gateway）是封包離開目前網路時，要先交付的下一站路由器 IP 位址。路由表（Routing Table）則保存「目的網路應交給哪個下一站或介面」的規則。
預設路由（Default Route）是路由表中的一條特殊規則。當目的位址沒有其他更明確的路由可用時，設備才會採用它。IPv4 以 0.0.0.0/0 表示所有尚未匹配的目的位址，這條規則通常指向預設閘道：
0.0.0.0/0 → 192.168.0.1
預設路由 預設閘道
因此，預設閘道是一台下一站設備的位址。預設路由是路由表中指向該位址的規則。
| 項目 | 回答的問題 |
|---|---|
| 預設閘道 | 下一站路由器的 IP 是什麼，目前能否到達 |
| 路由表 | 是否有 0.0.0.0/0 指向正確的預設閘道 |
| DNS | 名稱能否轉換成 IP |
測試應依序進行：
1.1.1.1，確認路由表中的 Internet 出口可用。Ping 公網 IPv4 成功而 DNS 查詢（Lookup）失敗，故障範圍已縮小到解析器（Resolver）或 DNS 伺服器。此時不需要重設 WAN 鏈路。
RFC 1918 私有 IPv4 無法直接在 Internet 路由。內部用戶端送出封包時，Internet 出口設備會把原始來源位址（Source Address）改成 WAN 可使用的位址，這個動作稱為來源 NAT，許多設備介面與文章也稱它為 Outbound NAT。
多台內部主機共用同一個公網 IPv4 時，NAT 設備還要區分各條連線。對 TCP 與 UDP 而言，設備通常會保留可用的原始來源通訊埠。發生衝突或需要建立唯一對應關係時，才改用不同的外部來源通訊埠。這項機制稱為通訊埠轉換（Port Address Translation，PAT）。
圖（十一）來源 NAT 搭配通訊埠轉換讓多條連線共用公網 IPv4
圖片來源：NetworkAcademy.io：NAT Overload（PAT）
PAT 主要用於多台主機共用單一公網 IPv4。一對一 NAT 可以只轉換位址。OPNsense 的自動來源 NAT 會處理這種共用情境。若規則啟用
Static-port，則會要求 pf 保留 TCP／UDP 的來源通訊埠。
執行 NAT 的設備會在狀態表（State Table）保存轉換關係，回應封包才能還原並送回原用戶端。一般單一 WAN、單一外部 IPv4 的環境，可使用防火牆自動產生的來源 NAT 規則。
使用浮動公網 IPv4 時，位址可能在重新連線或 ISP 更新租約後改變。外部使用者若連向舊位址，就無法找到服務。動態 DNS（Dynamic DNS，DDNS）會在公網 IPv4 改變後更新 DNS 紀錄，讓固定的網域名稱重新指向目前位址。
圖（十二）DDNS 在浮動公網 IPv4 改變後更新 A 紀錄
OPNsense 可安裝 os-ddclient 外掛，並在 Services → Dynamic DNS → Settings 設定服務提供商（Provider）、主機名稱（Hostname）、IP 檢查方式（Check IP Method）與監看介面（Interface）。
DNS TTL 允許解析器在一段時間內保留舊結果，因此各解析器會隨 TTL 與快取到期時間逐步取得更新後的紀錄。固定公網 IPv4 可直接建立一般 A 紀錄，不需要週期性 DDNS 更新。詳細的 DNS 相關教學後面會再次提到。
fw01 的 WAN 已經能從上游路由器取得 DHCP 位址，今天接著確認這條 WAN 路徑如何取得位址、建立預設路由並具備來源 NAT 規則。fw01 先使用私有 IPv4 連到持有公網 IPv4 的上游路由器，因此內部流量對外時會依序經過 OPNsense 與上游路由器兩次 NAT。
今天保留現有 DHCP WAN，不切換 PPPoE，也不改動 pve01～pve03 目前使用的初始閘道。完整欄位、PPPoE 切換條件與排錯方式請參考 GitHub 實作文件：
GitHub 詳細實作文件：Day 12｜OPNsense WAN、雙重 NAT、PPPoE 與 DDNS
到 Interfaces → Overview 查看 WAN：
圖（十三）從介面總覽確認 WAN 裝置、DHCP 位址與上游閘道
畫面顯示 WAN 使用 vtnet0、Link Type 為 dhcp，取得 192.168.0.84/24，Gateway 為 192.168.0.1，而且路由清單包含 default。192.168.0.84 是私有 IPv4，代表公網 IPv4 位於上游設備。這就是目前雙重 NAT 的第一個判斷依據。
因為 WAN 連接的是私有上游網段，到 Interfaces → WAN 取消 Block private networks、保留 Block bogon networks，再儲存並套用：
圖（十四）上游使用私有網段時取消封鎖私有來源網路
若維持 Block private networks，OPNsense 會把從 192.168.0.0/24 上游網段進入 WAN 的封包視為應封鎖的私有來源。這項調整只適用於 WAN 前方確實還有私有上游路由器的情境。WAN 直接持有公網 IPv4 時，不應照抄。
依序確認 DHCP Gateway 顯示 Online，再到 Interfaces → Diagnostics → Ping，Hostname or IP 填 1.1.1.1、Address Family 選 IPv4、Source address 選 WAN 位址，再執行 Ping。接著使用 DNS Lookup 查詢 www.opnsense.org。只有上游閘道、公網 IPv4 與 DNS 都分別成功，才能確認 WAN 不只是取得位址，而是已具備完整的名稱解析與對外路徑。
圖（十五）確認 DHCP 建立的 IPv4 預設閘道可用
圖（十六）從 fw01 驗證公網 IPv4 可達性
圖（十七）從 fw01 驗證 DNS 名稱解析
到 Firewall → NAT → Source NAT，確認 Mode 使用 Automatic Source NAT rule generation：
圖（十八）確認 OPNsense 自動產生來源 NAT 規則
畫面顯示 OPNsense 已為內部網路產生轉換至 WAN Address 的自動規則。這項設定與介面總覽共同呈現目前雙重 NAT 的預定路徑。實際封包轉換可再透過內部用戶端連線、狀態表或封包擷取確認。
新版 OPNsense 要先到 Interfaces → Devices → Point-to-Point 建立 PPPoE 裝置，再到 Interfaces → Assignments 指派：
圖（十九）新版 OPNsense 的 PPPoE Point-to-Point 裝置設定位置
這張圖只用來確認 Link Type、Link interface、Username、Password 等欄位的位置，不能證明 PPPoE 已經連線。今天不建立 pppoe0，也不儲存或套用這一頁的內容。真正切換以前必須準備 Console 或獨立救援路徑。
| 驗證 | 主要證據 | 可以得到的結論 |
|---|---|---|
| 驗證一：DHCP WAN | Interface Overview | fw01 WAN 使用私有 DHCP 位址與上游預設閘道 |
| 驗證二：私有上游 | WAN 的 Block private networks 未勾選 | 私有上游流量不會被這項 WAN 來源檢查直接封鎖 |
| 驗證三：對外路徑 | Gateway、WAN Ping 與 DNS Lookup | 預設路由、公網 IPv4 可達性與名稱解析分別成立 |
| 驗證四：來源 NAT | Automatic Source NAT rule generation | 內部網路已有轉換至 fw01 WAN Address 的自動規則 |
PPPoE 畫面只記錄替代接取方式的設定入口，因此列為補充，不列入已完成的連線驗證。
下一篇是 Day 13｜從 VLAN 到安全區域：802.1Q、跨網段路由與 OPNsense 介面。我們會在 OPNsense 建立 Management、Service、Database、Backup 與 Bastion DMZ 的 VLAN Interface。本日先建立網路邊界與 Gateway，通行權限會在後續的最小權限規則中設定。
iThome鐵人賽
看影片追技術