一台 PVE 主機上的 VM 能夠連上網路，封包會經過 VM 虛擬網卡、TAP 虛擬乙太網路裝置、Linux 橋接器（Linux Bridge）與實體網路介面卡（NIC），最後才離開主機。如果中間還使用網卡綁定（Bond）與 VLAN（虛擬區域網路），封包路徑會再多出鏈路聚合與 VLAN 標記的處理。
這一篇從最底層的實體網卡開始，逐層往上理解 PVE 的虛擬網路。等這條路徑建立完成，再把管理網路、虛擬機網路、Corosync 與 Ceph 傳輸需求放到適合的網路上。
這一篇要回答三個問題：
這一天以第一層實體層與第二層資料連結層的傳輸路徑為主，再補充第三層 IP 與路由如何銜接，不急著撰寫防火牆規則。封包能到達 OPNsense，和 OPNsense 是否允許封包通過，是兩個不同階段的問題。
本文閱讀方式
- 完整理解技術與底層原理：依序閱讀全文。
- 掌握完成部署所需的基本概念：優先閱讀標有「⭐」的章節。
- 快速了解當天的部署內容：閱讀文末的 Lab／實作章節。
- 跟著系列建立完整系統：依照 GitHub 詳細部署文件 的天數順序操作。
在沒有 Bond 與 VLAN 的最簡單情況下，PVE 的網路可以由下往上讀成：
圖（一）PVE 虛擬網路的基本路徑。
若主機使用兩張網卡做備援，Bond 會位於實體網卡與 Linux 橋接器之間：
圖（二）加入 Bond 後的虛擬網路路徑。
VLAN 可以想像成網路封包上的分類標籤，必須由 Linux 橋接器、Bond、實體網卡與交換器共同正確傳遞。先理解實體與虛擬裝置的上下關係，再談 VLAN，會比較容易。
要提到網路肯定要先說到 OSI 七層模型，它是一套共同語言：看到網路線沒接、VLAN 設錯、路由不存在或服務沒回應時，可以先判斷問題大約位於哪一層。
圖（三）OSI 七層模型。圖源：HiNet 企業上網
這次我們只會用到前三層：
第四層傳輸層以上則會在後續服務部署時繼續出現。例如 TCP／UDP 連接埠屬於傳輸層，HTTP、DNS 與 PostgreSQL 則屬於更上層的協定或應用服務。
以下的第一階段至第五階段，是本文用來說明 PVE 網路元件的堆疊順序，不是 OSI 模型的層級。
實體 NIC 是主機真正連接網路線的介面，例如 eno1、enp3s0，或 Lab 中辨識到的 nic0、nic1、ens20、ens21。名稱可能因硬體、PCI 位置與系統版本不同而改變。
實體 NIC 這一層決定的是：
UP。在 PVE 中，若實體網卡已經成為 Linux Bridge 的連接埠（Port），通常不再把宿主機 IP 直接設在實體網卡上，而是把 IP 設在上層的 Bridge。主機改由 Bridge 介面參與該第三層 IP 網路。
例如 PVE 把 eno1 加入 vmbr0 後，eno1 是封包離開主機的實體出口，PVE 宿主機的管理 IP 則設在 vmbr0。
查看實體介面時，可以交叉比對連線狀態、MAC 位址與 Bridge Port：
ip -br link
ip -br address
bridge link
ethtool <實際介面名稱>
這些指令會在後面的 Lab 畫面中搭配 PVE 網頁介面一起確認。
這裡的「獨立 NIC」是指真正不同的實體網卡與網路線。例如正式環境可以讓管理網路使用一張實體 NIC、Corosync （叢集成員狀態、Quorum 與 HA 決策所需的叢集通訊）使用另一張實體 NIC、Ceph 傳輸再使用第三張實體 NIC。
它的優點是：
獨立 NIC 解決的是路徑與資源分離。
網卡綁定（Bond，也常稱為鏈路聚合）是把兩張以上的實體網卡組合成一個邏輯介面，例如 bond0。上層 Linux Bridge 不必分別連到每張實體網卡，而是把 bond0 當成自己的連接埠。
圖（四）兩張實體網卡透過 Bond 接到 Linux Bridge。
Bond 的主要用途有兩種：
常見模式如下：
active-backup（主動／備援）：同一時間主要由一張網卡傳輸，連線監測發現故障後再切換到備用網卡。概念最直接，通常不要求交換器建立 LACP 群組。802.3ad／LACP（鏈路聚合控制協定）：主機與交換器共同協商聚合連線，可同時使用多條成員鏈路，但交換器端也必須建立相符的聚合群組。balance-xor（XOR 雜湊平衡）：根據來源與目的位址等欄位計算雜湊值，再選擇傳輸介面。LACP 增加的是多條資料流（Flow）的總體吞吐量，不代表單一 TCP 連線會把兩張 1GbE 網卡直接相加成 2Gbps。封包會依 MAC 位址、IP 位址或連接埠等欄位計算雜湊，屬於同一條資料流的封包通常走同一條成員鏈路，避免封包順序混亂。
如果 LACP 的兩條線分別接到兩台交換器，兩台交換器必須支援堆疊（Stack）、MLAG（多機箱鏈路聚合）或同類型的跨機聚合能力。兩台彼此獨立、沒有共同控制平面的交換器，不能直接組成同一個 LACP 群組。
Linux 橋接器（Linux Bridge）是 Linux 核心（Linux Kernel）提供的第二層軟體交換器。它會學習來源 MAC 位址，建立 MAC 位址轉送表，再依目的 MAC 位址把乙太網路框架（Ethernet Frame）送到適合的連接埠。
可以把它想成裝在 PVE 主機裡的一台軟體交換器：
圖（五）Linux Bridge 連接宿主機、實體網卡與 VM。
Bridge 常見的三種用法是：
VLAN aware（可感知 VLAN），承載並區分多個 VLAN 的帶標籤框架。詳細行為會在 VLAN 章節說明。Linux Bridge 只負責第二層轉送。若把 IP 位址設在 Bridge 上，代表 PVE 宿主機自己也加入該第三層 IP 網路。只負責承載 VM 多 VLAN 中繼流量（VM Trunk）或節點間傳輸的 Bridge，則可以不設定宿主機 IP。
用實際例子來解釋：
eno1、eno2：只作為 bond0 的成員，不設定 IP
bond0：只作為 vmbr0 的連接埠，不設定 IP
vmbr0：PVE 宿主機真正參與管理網路，因此在這裡設定 IP
在 PVE 網頁介面替 VM 新增網路裝置（Network Device）時，建立的是 VM 看得見的虛擬網卡。選擇 VirtIO 型號（VirtIO Model）時，QEMU 向 VM 提供半虛擬化網卡。PVE 宿主機端則會建立對應的 TAP 虛擬乙太網路裝置，並把 TAP 接到指定的 Linux Bridge。
圖（六）TAP 與 VM 內 VirtIO NIC 的對應關係。
白話來說，VirtIO NIC 讓 VM 像使用一張自己的網路介面卡。TAP 則是這張虛擬網卡在 PVE 宿主機端的出口。VirtIO 不需要完整模擬某一款傳統實體網卡，因此通常能減少額外模擬成本。
Linux 還有另一種名稱相近的 TUN 裝置。簡單來說，TAP 收送包含 MAC 位址的第二層乙太網路框架，因此可以接上 Linux Bridge。TUN（虛擬點對點網路裝置）則收送第三層 IP 封包，常用於 VPN 或路由型通道。PVE 將 QEMU VM 橋接到 vmbr 時使用 TAP，TUN 不在這條 VM Bridge 路徑中。VirtIO NIC 是 VM 內看到的虛擬網卡，TAP 則是它在 PVE 宿主機端對應的虛擬網路裝置。
要注意宿主機與 VM 看到的名稱並不相同：
net0、MAC 位址、網卡型號、Bridge 與 VLAN Tag。eth0、ens18 或其他可預測介面名稱。這些名稱代表同一條封包路徑上的不同觀察位置。Linux 容器（LXC Container）通常使用 veth pair（成對虛擬乙太網路介面），概念同樣是將容器端介面接到宿主機的 Linux Bridge，但實作方式與 QEMU VM 的 TAP 不完全相同。
VLAN（Virtual Local Area Network，虛擬區域網路）使用 IEEE 802.1Q 標籤，在同一套實體網路上切出不同的第二層廣播網域（Broadcast Domain）。同一廣播網域中的裝置會收到彼此送出的廣播封包。分到不同 VLAN 後，這些廣播不會直接跨到另一個 VLAN。
白話來說，如果每個服務都要各自使用實體交換器和網路線，接線與擴充會非常複雜。VLAN 讓同一台可管理式交換器、同一張網卡與同一條線路同時承載多個邏輯網路，再用 VLAN ID 區分封包屬於哪一區。
這些 VLAN 雖然共用實體線路，但在第二層是不同網路。若要跨 VLAN 通訊，必須經過路由器。
同一條 Trunk 也可以同時出現帶標籤與未帶標籤流量。帶標籤框架直接依 VLAN ID 分類。未帶標籤框架則依該連接埠設定的 PVID 或原生 VLAN（Native VLAN）決定歸屬。若沒有相符的允許規則，封包就會被丟棄。
圖（七）Linux Bridge 對 VLAN 封包進行分類與轉送。
Trunk 兩端的 PVID／Native VLAN 必須一致。若 PVE 把未標籤流量視為 VLAN 10，交換器卻把它歸入 VLAN 20，封包就會進入錯誤的廣播網域。
VLAN aware 即可。在 PVE 中開啟 VLAN aware（可感知 VLAN），代表 Linux Bridge 看得懂 VLAN 標籤，能依 VLAN ID 處理與過濾框架。替 VM Network Device 填入 VLAN Tag，例如 20，PVE 會把該 VM 連接埠當成 VLAN 20 的邏輯 Access Port。
此時 VM 裡不必再建立 VLAN 20 子介面。VM 送出的普通未標籤框架進入 PVE 後，由 PVE 加上 VLAN 20 標籤。回程封包進入 VM 前，PVE 再移除標籤。對 VM 而言，它就像接在實體交換器的 VLAN 20 Access Port 上。
若要讓 PVE 宿主機自己加入某個 VLAN，則可在 VLAN-aware Bridge 上建立 Linux VLAN 子介面，例如 vmbr1.10。IP 設在 vmbr1.10，而不是設在只負責承載整條 Trunk 的 vmbr1。
vmbr1：承載多個 VLAN，本身不設定 IP
vmbr1.10：讓 PVE 宿主機加入 VLAN 10，在這裡設定管理 IP
VLAN 只負責把第二層網路分開，不負責替不同網段轉送封包。不同 VLAN 要互相通訊，依然需要 OPNsense 或其他第三層設備進行路由（Routing）。哪些來源可以通往哪些目的地，再由防火牆規則決定。
三者可以一起使用，但不能互相取代：
| 技術 | 主要解決的問題 | 無法單獨解決的問題 |
|---|---|---|
| 獨立實體網卡 | 分離實體路徑與頻寬 | 單張網卡或單一路徑故障後的接手 |
| 網卡綁定（Bond） | 多張網卡的路徑備援或整體吞吐量 | 不同網路的廣播網域隔離與防火牆政策 |
| VLAN（虛擬區域網路） | 在共用鏈路上切分邏輯網路 | 共用網卡、線路與交換器的頻寬競爭及故障 |
MTU（Maximum Transmission Unit，最大傳輸單元）代表網路介面一次可以傳送多大的資料單位。一般乙太網路常使用 MTU 1500。巨型框架（Jumbo Frame）則是把 MTU 調大，常見設定為 9000，讓相同資料可以用較少的封包次數傳送。
若要使用較大的 MTU，用戶端、VM 虛擬網卡、TAP、Linux Bridge、VLAN、Bond、實體網卡與交換器整條路徑都必須相容。中間任何一段使用較小 MTU，都可能形成小封包正常、大封包逾時的間歇性故障。
理解底層元件後，再來看本系列規劃的四種網路角色：
這裡先簡單介紹各自的用途。後續章節會配合實際部署，進一步說明設定方式與彼此之間的關係。
| 網路角色 | 保存或傳輸的內容 | 斷線時的主要影響 |
|---|---|---|
| 管理網路（Management Network） | PVE 網頁介面、API、SSH 與節點管理 | 管理者無法操作節點，但既有 VM 不一定立刻停止 |
| VM VLAN 中繼網路（Guest VLAN Trunk） | 服務、資料庫、跳板機等 VM 流量 | VM 無法連到閘道或其他服務 |
| Corosync 網路（Corosync Network） | 節點成員狀態、投票與法定票數訊息 | 叢集可能失去法定票數，限制設定修改與 HA 決策 |
| Ceph 儲存網路（Ceph Storage Network） | VM 磁碟存取、節點間副本同步、復原與重新平衡流量 | 儲存延遲上升，嚴重時可能暫停儲存輸入輸出 |
管理網路讓管理者操作 PVE 網頁介面、API 與 SSH。它不和所有對外服務一起直接暴露。Lab 前期先使用路由器配發的 192.168.0.x 完成建置，之後再把管理入口移到 VLAN 10，並透過 VPN 存取。
VM VLAN 中繼網路讓服務、資料庫、跳板機等 VM 共用同一組虛擬與實體路徑，但分別屬於不同 VLAN。這條路徑需要從 L2 VM、L1 PVE、L0 宿主機一直到 OPNsense 都正確傳遞 VLAN 標籤。
Corosync 傳輸量通常不大，但很在意穩定性與延遲。它負責節點成員狀態（Membership）、投票（Vote）與法定票數（Quorum）訊息。若封包因壅塞或丟失而長時間無法到達，叢集可能把正在運作的節點判斷為失聯。因此 Lab 讓它使用獨立的虛擬交換器，不必繞經 OPNsense。
Lab 使用獨立的 10.77.80.0/24 與 L0 vmbr5 承載 Corosync，實際位址與 PVE 畫面留到後面的 Lab 段落一起對照。
Ceph 需要透過網路傳輸 VM 磁碟存取、節點間資料副本、復原與重新平衡流量。平時看似空閒的網路，在資料同步或節點恢復時可能出現大量傳輸，因此 Lab 另外使用一座虛擬交換器承載 Ceph 流量。
Ceph 文件會把傳輸路徑分為用戶端存取網路（Public Network）與叢集內部複寫網路（Cluster Network）。這裡的 Public Network 不是指 WAN 或公開網路：
硬體與交換器連接埠足夠時，這兩種流量可以再次分到不同實體鏈路。為控制網路複雜度，本 Lab 共同使用同一個 10.77.70.0/24 網路，不另外配置 Cluster Network。
今天只建立 Ceph 所需的網路傳輸路徑，Ceph 的磁碟角色、資料配置或服務部署會留到後續。
Corosync 與 Ceph 的內部網路都不設定預設閘道（Default Gateway），因為三個節點位於各自的同一子網，彼此直接交換封包即可。
原理說明完成後，接著直接打開 PVE 畫面對照。正式文章只帶讀與網路角色有關的畫面。完整操作步驟則放在 GitHub 實作文件，要完整重現實驗環境可以參考一下。
GitHub 實作文件：詳細部署步驟
登入 L0 的 PVE 網頁介面，選取左側節點 pve-l0，再進入 System → Network。這個畫面顯示的是 L0 自己的 Linux Bridge 與實體網卡，不是 pve01～pve03 裡面的網路設定。
畫面中的 L0 節點名稱為 pve，本文統一稱為 pve-l0。
圖（八）L0 pve-l0 的 Network 畫面，可看見實體管理網路、內部 VLAN Trunk、Ceph 與 Corosync 使用的不同 Bridge。
vmbr0：接上實體網卡，連接現有路由器、L0 管理與 Lab 外部網路。vmbr2：沒有實體連接埠，作為內部 VLAN Trunk。
vmbr2.10：讓 L0 加入 VLAN 10 的管理介面，設定 10.77.10.10/24，不設定 Gateway。vmbr4：沒有實體連接埠，承載 Ceph 儲存網路。vmbr5：沒有實體連接埠，承載 Corosync 網路。vmbr0 有 L0 的管理 IP 與實體 Bridge Port。vmbr2、vmbr4、vmbr5 都是只在 Lab 內部交換封包的虛擬交換器，因此 Bridge Port 與 Gateway 留白。vmbr2 開啟 VLAN aware，因為它要承載 VLAN 10～50。vmbr4 與 vmbr5 各自只有一個未標籤網路，不必開啟 VLAN-aware。
vmbr2.10 是掛在 vmbr2 上的 VLAN 10 子介面。今天先設定 10.77.10.10/24 且不填 Gateway，替之後從 L0 管理 OPNsense 預留路徑。
接著在 L0 左側選取 VM 101 pve01，進入 Hardware。這裡看到的是 L1 PVE 這台 VM 擁有的四張虛擬網卡：
圖（九）從 L0 查看 VM 101 pve01 的 Hardware，四張 Network Device 分別接到四種用途不同的 L0 Bridge。
net0 → L0 vmbr0：前期安裝與管理。net1 → L0 vmbr2：VLAN 10～50 中繼網路。net2 → L0 vmbr4：Ceph 儲存網路。net3 → L0 vmbr5：Corosync 網路。這四張網卡是 L0 提供給 pve01 的虛擬硬體。進入 pve01 後，它們會變成 nic0、nic1、ens20、ens21 或其他 Linux 介面名稱，因此要使用 MAC 位址對照，不能只靠名稱猜測。
再登入 pve01 的 PVE 網頁介面，選取節點 pve01 → System → Network。現在看到的是 pve01 內部如何使用剛才四張虛擬網卡。
圖（十）pve01 的 L1 Network 畫面。這張截圖拍攝於後續管理網路已切換完成的狀態，因此可看見 vmbr1.10 的 Gateway 已是 10.77.10.1，而 vmbr0 已移除舊 Gateway。Day 05 當下只會先建立 vmbr1.10 與管理 IP，Gateway 維持留白。
先在三台 L1 建立 vmbr1.10，分別設定 10.77.10.11/24、.12/24、.13/24，但全部不填 Gateway。此時它們只是預先加入 VLAN 10，原本 vmbr0 的 192.168.0.x 與 Default Gateway 負責管理及對外連線。等 OPNsense 與規則完成後，才切換為 10.77.10.1。
三台 L1 PVE 的第四張 VirtIO 網卡分別設定 10.77.80.11/24、.12/24、.13/24，全部不設預設閘道。這張網卡直接承載 Corosync，不另外建立 Linux Bridge。本次 pve01 的實際介面名稱為 ens21。其他節點要依 MAC 位址確認，不能直接照抄介面名稱。
三台 L1 的第三張 VirtIO 網卡則接到各自的 vmbr2，並設定下列 Ceph 儲存網路位址。這條路徑會經由 L0 vmbr4 讓三個節點互相傳輸資料：
| 節點 | Ceph 儲存網路 IP | 預設閘道 |
|---|---|---|
| pve01 | 10.77.70.11/24 |
留白 |
| pve02 | 10.77.70.12/24 |
留白 |
| pve03 | 10.77.70.13/24 |
留白 |
L0 vmbr4 與三台 L1 vmbr2 都不是 VLAN Trunk，也不需要開啟 VLAN aware。它們只承載目前這一個未帶標籤的 Ceph 儲存網路。設定完成後，三個 10.77.70.x 位址必須能互相 Ping。L0 Bridge 本身不需要設定同網段 IP。
本日實作會完成網路與 Ceph 磁碟的前置準備：
vmbr2.10，並在三台 L1 建立 vmbr1.10。只預先設定管理 IP，不設定新的預設閘道。pve01～pve03 各新增一顆 40 GiB 空白磁碟，保留給 Day 07 建立 Ceph OSD。10.77.70.11～.13 與 10.77.80.11～.13 各自在同網段互通。PVE 宿主機要加入 VLAN 時，不把 IP 直接填在只承載 Trunk 的 vmbr1，而是在 VLAN-aware Bridge 上建立 Linux VLAN 子介面。本日已建立 vmbr1.10 並設定 10.77.10.11～.13/24，但不填 Gateway。之後只需要把管理出口切換到 10.77.10.1，同時移除 vmbr0 的舊 Default Gateway 就可以了。
vmbr2 名稱，也可能代表完全不同的網路用途，必須連同所在主機一起判斷。下一篇是 Day 06｜讓虛擬機可以重複部署：Template、Cloud-Init 與 Debian Cloud Image。底層 Bridge、Trunk 與節點內部網路完成後，下一步先建立可重複使用的 VM 基線。Day 07 再使用已準備好的 Corosync 與 Ceph Storage Network 組成 PVE Cluster，並開始介紹 Ceph 的儲存角色與部署方式。
iThome鐵人賽
看影片追技術