Dell Automation Platform: Віртуальна машина NativeEdge не може отримати DHCP IP з мережевого мосту

Наступні спостереження спостерігаються при зіткненні з ситуацією:

• VM розгортається та підключається до мостового сегмента віртуальної мережі за допомогою гетерогенного інтерфейсу зв'язку (приклад: Активний/резервний зв'язок із використанням wlp6s0 для Wi-Fi та enp3s0 для Ethernet)
• VM не отримує IP-адресу за допомогою DHCP.
• У операційній системі віртуальної машини статус інтерфейсного з'єднання — UP (ethtool показує виявлене зв'язок: Так)
• Логи NetworkManager віртуальної машини (за допомогою journalctl -u NetworkManager -f) розкрити DHCP DISCOVER Пакети надсилаються, але DHCP немає. OFFER або ACK Повідомлення завжди отримуються.
• Ручне призначення статичної IP-адреси для віртуальної машини успішно працює, дозволяючи зовнішні пінги та підключення до шлюзу.
• Використання сегмента віртуальної мережі NAT замість сегмента мосту успішно призначає внутрішню/NAT IP-адресу віртуальній машині за допомогою DHCP.

Інженерія підтвердила, що гетерогенні адаптери зв'язку підтримують лише створення сегментів віртуальної мережі NAT. Мостові віртуальні сегменти мережі через гетерогенний зв'язок не підтримуються.

Це свідоме дизайнерське рішення, зроблене для забезпечення успішного та надійного підключення NativeEdge до найширшого вибору сторонніх Wi-Fi точок доступу (AP). Проблема виникає у фундаментальних відмінностях у тому, як стандартні мережі Ethernet та 802.11 (Wi-Fi) обробляють трафік другого рівня:

• Обмеження Wi-Fi Bridging: Стандарт 802.11 вимагає точки доступу для автентифікації однієї конкретної MAC-адреси для кожного клієнтського з'єднання. Справжній мережевий мост дозволяє проходити кілька MAC-адрес через один інтерфейс, що Wi-Fi точки доступу зазвичай відхиляють з міркувань безпеки.
• Чому DHCP не працює: Віртуальна машина, що запитує IP за допомогою DHCP, ще не має маршрутизованої IP-адреси. Вона транслює DHCP DISCOVER пакет на рівні каналу даних (рівень 2), використовуючи власну унікальну віртуальну MAC-адресу. Коли зовнішній DHCP-сервер відповідає DHCP OFFER, він націлений на віртуальний MAC. Оскільки цей вторинний MAC не автентифікується Wi-Fi точкою доступу, точка доступу (або правила фаєрволу для переадресації хоста) відкидає неавтентифікований зворотний трафік, порушуючи DHCP-рукостискання.
• Чому працює статична IP: При призначенні статичної IP VM обходить потребу в трансляції DHCP рівня 2. Мережевий стек гіпервізора використовує Proxy ARP (MAC-NAT) та стандартну маршрутизацію рівня 3. Хост перехоплює вихідний трафік VM, маршрутизує його від імені VM, маскуючи трафік за основною, автентифікованою MAC-адресою хоста. Оскільки трафік правильно маршрутизується на рівні 3, а не на рівні 2, мережевий зв'язок тече.

У поточній документації немає запису про це обмеження, але воно додається до Нотаток до релізу у майбутньому випуску.

Щоб вирішити або обійти цю проблему, скористайтеся одним із наступних методів:

1. Використовуйте сегмент мережі NAT: Якщо використовується гетерогенний адаптер зв'язку (змішаний Wi-Fi та Ethernet), налаштуйте сегмент віртуальної мережі на використання NAT замість Bridge.
2. Присвоїти статичну IP-адресу: Якщо на гетерогенному зв'язку потрібне суворо мережеве з'єднання, призначте статичну IP-адресу віртуальній машині вручну. Статичні IP-конфігурації обходять обмеження DHCP і дозволяють нормальний трафік.