Plataforma de automatización de Dell: La VM de NativeEdge no puede obtener la IP de DHCP del puente de red

Al encontrarse con la situación, se observan las siguientes observaciones:

• Una VM se implementa y se conecta a un segmento de red virtual con puente mediante una interfaz de enlace heterogénea (ejemplo: Vinculación activa/de respaldo mediante wlp6s0 para Wi-Fi y enp3s0 para Ethernet)
• La VM no puede obtener una dirección IP mediante DHCP.
• Dentro del sistema operativo de la máquina virtual, el estado del enlace de la interfaz es UP (ethtool muestra el enlace detectado: Sí)
• Registros de NetworkManager de la VM (mediante journalctl -u NetworkManager -f) revelan DHCP DISCOVER se están enviando paquetes, pero no hay DHCP OFFER o ACK Los mensajes se reciben alguna vez.
• La asignación manual de una dirección IP estática a la máquina virtual funciona correctamente, lo que permite pings externos y conectividad de gateway.
• El uso de un segmento de red virtual NAT en lugar de un segmento de puente asigna correctamente una dirección IP interna/NAT a la VM mediante DHCP.

El equipo de ingeniería confirmó que los adaptadores de enlace heterogéneos solo admiten la creación de segmentos de red virtual NAT. Los segmentos de red virtual puenteados a través de un enlace heterogéneo no son compatibles.

Esta es una elección de diseño deliberada para garantizar que los terminales NativeEdge se conecten de manera exitosa y confiable a la mayor variedad posible de puntos de acceso (AP) Wi-Fi de otros fabricantes. El problema se deriva de las diferencias fundamentales en la forma en que las redes Ethernet y 802.11 (Wi-Fi) estándar manejan el tráfico de capa 2:

• Limitación de puente de Wi-Fi: El estándar 802.11 requiere un punto de acceso para autenticar una única dirección MAC específica por conexión de cliente. El verdadero puente de red permite que varias direcciones MAC pasen a través de una sola interfaz, que los puntos de acceso Wi-Fi generalmente rechazan por razones de seguridad.
• Por qué falla DHCP: Una máquina virtual que solicita una IP mediante DHCP aún no tiene una dirección IP enrutable. Transmite un DHCP DISCOVER paquete en la capa de enlace de datos (capa 2) utilizando su propia dirección MAC virtual única. Cuando el servidor DHCP externo responde con un DHCP OFFER, se dirige a esa MAC virtual. Debido a que esa MAC secundaria no se autentica con el punto de acceso Wi-Fi, el punto de acceso (o las reglas de firewall de reenvío del host) descarta el tráfico de retorno no autenticado, rompiendo el protocolo de enlace DHCP.
• Por qué funciona una IP estática: Cuando se asigna una IP estática, la VM omite la necesidad de la transmisión DHCP de capa 2. La pila de redes del hipervisor utiliza ARP de proxy (MAC-NAT) y enrutamiento estándar de capa 3. El host intercepta el tráfico saliente de la VM, lo enruta en nombre de esta y enmascara el tráfico detrás de la dirección MAC autenticada principal del host. Debido a que el tráfico se enruta correctamente en la capa 3 en lugar de puentearse en la capa 2, la comunicación de red fluye.

No hay registro de esta limitación en la documentación actual, pero se agregará a las notas de la versión en la próxima versión.

Para resolver o solucionar este problema, utilice uno de los siguientes métodos:

1. Usar un segmento de red NAT: Si utiliza un adaptador de enlace heterogéneo (combinación de Wi-Fi y Ethernet), configure el segmento de red virtual para utilizar NAT en lugar de Bridge.
2. Asigne una IP estática: Si se requiere estrictamente una conexión de red con puente en el enlace heterogéneo, asigne manualmente una dirección IP estática a la máquina virtual. Las configuraciones de IP estáticas omiten la limitación de DHCP y permiten el flujo de tráfico normal.