Plataforma de automação da Dell: A VM do NativeEdge não consegue obter o IP DHCP da ponte de rede

As seguintes observações são vistas ao se deparar com a situação:

• Uma VM é implementada e conectada a um segmento de rede virtual conectado por ponte usando uma interface de vínculo heterogêneo (por exemplo: Vínculo ativo/de backup usando wlp6s0 para Wi-Fi e enp3s0 para Ethernet)
• A VM não consegue obter um endereço IP usando DHCP.
• Dentro do sistema operacional da VM, o status do link da interface é UP (ethtool mostra o link detectado: Sim)
• Logs do NetworkManager da VM (usando journalctl -u NetworkManager -f) revelar DHCP DISCOVER pacotes estão sendo enviados, mas não DHCP OFFER ou ACK As mensagens são sempre recebidas.
• A atribuição manual de um endereço IP estático à VM funciona com sucesso, permitindo pings externos e conectividade de gateway.
• Usar um segmento de rede virtual NAT em vez de um segmento Bridge atribui com sucesso um endereço IP interno/NAT à VM usando DHCP.

A engenharia confirmou que adaptadores de ligação heterogêneos só dão suporte à criação de segmentos de rede virtual NAT. Os segmentos de rede virtual de ponte em um vínculo heterogêneo não são compatíveis.

Essa é uma escolha deliberada de design feita para garantir que o endpoint NativeEdge se conecte com sucesso e confiança à maior variedade possível de pontos de acesso (APs) Wi-Fi. O problema decorre das diferenças fundamentais em como as redes Ethernet padrão e 802.11 (Wi-Fi) lidam com o tráfego de camada 2:

• Limitação de Wi-Fi Bridging: O padrão 802.11 exige um ponto de acesso para autenticar um endereço MAC único e específico por conexão de client. A verdadeira ponte de rede permite que vários endereços MAC passem por uma única interface, que os APs Wi-Fi geralmente rejeitam por motivos de segurança.
• Por que o DHCP falha: Uma VM solicitando um IP usando DHCP ainda não tem um endereço IP roteável. Ele transmite um DHCP DISCOVER pacote na camada de link de dados (Camada 2) usando seu próprio endereço MAC virtual exclusivo. Quando o servidor DHCP externo responde com um DHCP OFFER, ele tem como alvo esse MAC virtual. Como esse MAC secundário não é autenticado com o ponto de acesso Wi-Fi, o ponto de acesso (ou as regras de firewall de encaminhamento do host) descarta o tráfego de retorno não autenticado, quebrando o handshake DHCP.
• Por que um IP estático funciona: Ao atribuir um IP estático, a VM ignora a necessidade de transmissão DHCP de camada 2. A pilha de rede do hypervisor usa proxy ARP (MAC-NAT) e roteamento padrão de camada 3. O host intercepta o tráfego de saída da VM, o encaminha em nome da VM, mascarando o tráfego por trás do endereço MAC principal autenticado do host. Como o tráfego é roteado corretamente na Camada 3, em vez de ser feito em ponte na Camada 2, a comunicação de rede flui.

Não há registro dessa limitação na documentação atual, mas ela é adicionada às notas da versão futura.

Para resolver ou contornar esse problema, use um dos seguintes métodos:

1. Use um segmento de rede NAT: Se estiver usando um adaptador de vínculo heterogêneo (Wi-Fi e Ethernet mistos), configure o segmento de rede virtual para usar NAT em vez de Bridge.
2. Atribua um IP estático: Se uma conexão de rede com ponte for estritamente necessária no vínculo heterogêneo, atribua manualmente um endereço IP estático à VM. As configurações de IP estático ignoram a limitação de DHCP e permitem o fluxo normal de tráfego.