Платформа автоматизации Dell: NativeEdge виртуальной машине не удается получить IP-адрес DHCP от сетевого моста

При возникновении ситуации наблюдаются следующие наблюдения:

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

Инженерный отдел подтвердил, что гетерогенные адаптеры связки поддерживают только создание сегментов виртуальной сети NAT. Связующие сегменты виртуальной сети через гетерогенную связку не поддерживаются.

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

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

Это ограничение не упоминается в текущей документации, но оно добавлено в примечания к выпуску в следующем выпуске.

Чтобы решить эту проблему или временно обойти ее, используйте один из следующих способов.

1. Использование сегмента сети NAT: При использовании адаптера гетерогенной связки (сочетание Wi-Fi и Ethernet) настройте сегмент виртуальной сети на использование NAT вместо моста.
2. Назначьте статический IP-адрес: Если для гетерогенной связки строго требуется связующее сетевое подключение, вручную назначьте ВМ статический IP-адрес. Статические конфигурации IP-адресов позволяют обойти ограничение DHCP и обеспечивают нормальный поток трафика.