Dell Automation Platform: NativeEdge VMがネットワーク ブリッジからDHCP IPを取得できない

この状況に遭遇すると、次の所見が表示されます。

• VMが導入され、異種ボンド インターフェイスを使用してブリッジ接続された仮想ネットワーク セグメントに接続されます(例: 次を使用したアクティブ/バックアップ ボンド wlp6s0 Wi-Fiおよび enp3s0 イーサネット用)
• VMがDHCPを使用してIPアドレスを取得できません。
• VMオペレーティング システム内では、インターフェイス リンクのステータスはUP (ethtool 「Link detected」と表示されます。はい)
• VMのNetworkManagerログ( journalctl -u NetworkManager -f)DHCPの表示 DISCOVER パケットは送信されているが、DHCPは送信されていない OFFER または ACK メッセージは常に受信されます。
• 固定IPアドレスをVMに手動で割り当てると正常に機能し、外部pingとゲートウェイ接続が許可されます。
• ブリッジ セグメントの代わりにNAT仮想ネットワーク セグメントを使用すると、DHCPを使用してVMに内部/NAT IPアドレスが正常に割り当てられます。

エンジニアリング チームは、異種ボンド アダプターがNAT仮想ネットワーク セグメントの作成のみをサポートすることを確認しました。異種ボンドを介したブリッジ仮想ネットワーク セグメントはサポートされていません。

これは、NativeEdgeエンドポイントを可能な限り多様なサード パーティー製Wi-Fiアクセス ポイント(AP)に正常かつ確実に接続できるようにするために、慎重に設計されています。この問題は、標準のイーサネット ネットワークと 802.11 (Wi-Fi) ネットワークがレイヤー 2 トラフィックを処理する方法の根本的な違いに起因しています。

• Wi-Fiブリッジングの制限事項: 802.11 標準では、アクセス ポイントがクライアント接続ごとに 1 つの特定の MAC アドレスを認証する必要があります。真のネットワーク ブリッジングでは、複数の MAC アドレスが 1 つのインターフェイスを通過できますが、Wi-Fi AP は通常、セキュリティ上の理由からこれを拒否します。
• DHCPが失敗する理由: DHCPを使用してIPを要求するVMには、ルーティング可能なIPアドレスがまだありません。DHCPをブロードキャストします DISCOVER パケットは、独自の一意の仮想MACアドレスを使用して、データリンク層(レイヤー2)で送信されます。外部DHCPサーバーがDHCPで応答すると、 OFFERの場合、その仮想 MAC をターゲットとします。そのセカンダリ MAC は Wi-Fi AP で認証されていないため、AP(またはホストの転送ファイアウォール ルール)は認証されていないリターン トラフィックをドロップし、DHCP ハンドシェイクを中断します。
• 静的IPが機能する理由: 静的IPを割り当てる場合、VMはレイヤー2 DHCPブロードキャストの必要性を回避します。ハイパーバイザーのネットワーキング スタックは、プロキシ ARP (MAC-NAT) と標準のレイヤー 3 ルーティングを使用します。ホストはVMのアウトバウンド トラフィックをインターセプトし、VMに代わってルーティングして、ホストのプライマリー認証済みMACアドレスの背後にトラフィックをマスキングします。トラフィックはレイヤ 2 でブリッジされるのではなく、レイヤ 3 で適切にルーティングされるため、ネットワーク通信はフローします。

現在のドキュメントにはこの制限の記録はありませんが、今後のリリースでリリース ノートに追加されます。

この問題を解決または回避するには、次のいずれかの方法を使用します。

1. NATネットワーク セグメントを使用します。異種ボンド アダプター(Wi-FiとEthernetの混在)を使用している場合は、ブリッジの代わりにNATを使用するように仮想ネットワーク セグメントを構成します。
2. 静的IPを割り当てます。異種ボンドでブリッジ ネットワーク接続が厳密に必要な場合は、固定IPアドレスをVMに手動で割り当てます。静的IP構成は、DHCPの制限をバイパスし、通常のトラフィックフローを許可します。