Dell 自動化平台：NativeEdge VM 無法從網橋取得 DHCP IP

遇到這種情況時，會看到以下觀察結果：

• 使用異構綁定介面部署 VM 並將其連接到橋接虛擬網段 （例如：使用以下方式使用主動/備份繫結 wlp6s0 適用於 Wi-Fi 和 enp3s0 適用於乙太網路）
• VM 無法使用 DHCP 取得 IP 位址。
• 在虛擬機器作業系統內，介面連結狀態為 UP （ethtool 顯示 偵測到的連結：是）
• VM 的 NetworkManager 記錄 （使用 journalctl -u NetworkManager -f） 顯示 DHCP DISCOVER 正在傳送封包，但沒有 DHCP OFFER 或 ACK 消息永遠收到。
• 手動指派靜態 IP 位址至 VM 可順利運作，允許外部 ping 和閘道連線。
• 使用 NAT 虛擬網段而不是網橋段，使用 DHCP 成功將內部/NAT IP 位址分配給虛擬機。

工程部門已確認異構綁定適配器僅支持創建 NAT 虛擬網段。不支援通過異構綁定橋接的虛擬網段。

這是經過深思熟慮的設計選擇，可確保 NativeEdge 端點能夠成功且可靠地連線至盡可能廣泛的第三方 Wi-Fi 存取點 （AP）。此問題源於標準乙太網和 802.11 （Wi-Fi） 網路處理第 2 層流量的方式的根本差異：

• Wi-Fi 橋接限制：802.11 標準要求接入點對每個用戶端連接的單個特定 MAC 位址進行身份驗證。真正的網路橋接允許多個 MAC 位址通過單個介面，Wi-Fi AP 通常會出於安全原因拒絕這些位址。
• DHCP 失敗的原因：使用 DHCP 要求 IP 的虛擬機還沒有可路由的 IP 位址。它會廣播 DHCP DISCOVER 數據鏈路層（第 2 層）上的數據包，使用其自己唯一的虛擬 MAC 位址。當外部 DHCP 伺服器使用 DHCP 回覆時 OFFER，它以該虛擬 MAC 為目標。由於該輔助 MAC 未通過 Wi-Fi AP 身份驗證，因此 AP（或主機的轉發防火牆規則）會丟棄未經身份驗證的返回流量，從而破壞 DHCP 握手。
• 為什麼靜態 IP 有效：分配靜態 IP 時，虛擬機會繞過對第 2 層 DHCP 廣播的需求。虛擬機管理程式的網路堆疊使用代理 ARP （MAC-NAT） 和標準第 3 層路由。主機攔截 VM 的出站流量，代表 VM 路由它，遮罩主機經過身份驗證的主 MAC 位址後面的流量。由於流量在第 3 層正確路由，而不是在第 2 層橋接，因此網路通信會流動。

目前的說明文件中沒有此限制的記錄，但已新增至即將發行的版本的版本資訊中。

若要解決此問題或變通解決此問題，請使用下列方法之一：

1. 使用 NAT 網段：如果使用異構綁定適配器（混合Wi-Fi和乙太網），請將虛擬網段配置為使用NAT而不是網橋。
2. 指派靜態 IP：如果異構綁定上嚴格需要橋接網路連接，請手動為 VM 分配靜態 IP 位址。靜態 IP 組態可略過 DHCP 限制，並允許正常流量。