Solução da comunidade

A ponte de VM do ZimaOS não consegue alcançar o anfitrião: macvtap ou NAT?

A user found that a ZVM bridged to eth0 could reach the LAN but not services on the ZimaOS host; switching the VM to NAT restored host connectivity.

Se uma VM do ZimaOS que utiliza “Bridge to eth0” receber um IP normal da LAN e conseguir aceder a outros dispositivos da LAN, mas não conseguir aceder ao próprio anfitrião ZimaOS, esse comportamento corresponde ao conhecido padrão de isolamento de anfitrião do macvtap. No tópico original, mudar a VM para NAT restabeleceu imediatamente a conectividade entre a VM e o anfitrião.

No entanto, o tópico não incluía uma confirmação da IceWhale de que o ZimaOS implementa definitivamente essa opção com macvtap do libvirt. A formulação correta deve, portanto, basear-se nos sintomas: o comportamento é semelhante ao isolamento do macvtap, em vez de afirmar que a implementação interna é um facto documentado.

O padrão de sintomas é altamente específico

  • A VM recebe um endereço DHCP na LAN física.
  • A VM consegue aceder aos routers e a outros dispositivos da LAN.
  • A VM não consegue resolver por ARP nem ligar-se ao IP do anfitrião ZimaOS.
  • O modo NAT restaura o acesso aos serviços executados no anfitrião.

Isto é diferente de uma VM que não tem rede alguma. O problema afeta sobretudo os fluxos de trabalho em que o sistema convidado precisa de contactar um serviço ligado diretamente ao anfitrião ZimaOS.

Porque é que isto se assemelha ao macvtap

O guia de isolamento do anfitrião do macvtap do libvirt documenta o mesmo padrão: um convidado que utilize uma interface direta/macvtap consegue aceder à rede externa, mas não consegue comunicar diretamente com o seu anfitrião de virtualização.

A atual referência do formato de rede do libvirt também distingue uma bridge existente no anfitrião de uma ligação direta macvtap e observa a limitação do macvtap na comunicação entre o anfitrião e o convidado.

Utilize NAT quando a VM tiver de aceder aos serviços do anfitrião ZimaOS

No teste da comunidade, o modo NAT foi a solução alternativa verificada. Se um proxy inverso dentro da VM apenas precisar de acesso de saída a um serviço no anfitrião ZimaOS, o NAT poderá ser mais simples do que forçar uma interface ligada à LAN.

Se o convidado também precisar de um endereço de primeira classe na LAN, uma segunda interface de VM numa rede virtual acessível pelo anfitrião é um padrão comum do libvirt, mas a possibilidade de o ZVM expor essa configuração de forma adequada depende da interface e da versão atuais do ZimaOS.

Estruture o proxy inverso em função do limite da rede

Se o Caddy ou o Nginx for executado numa VM enquanto o Home Assistant ou outro serviço for executado diretamente no anfitrião ZimaOS, verifique a acessibilidade do anfitrião antes de dedicar tempo à configuração de TLS ou do proxy. O guia de proxy inverso do ZimaOS é útil quando a conectividade básica de camada 3 estiver a funcionar.

Para a configuração geral de interfaces e IP, o guia de ligação de dispositivos do ZimaOS fornece uma referência independente.

Em resumo

O tópico confirma os sintomas de rede e a solução alternativa com NAT. Não confirma a implementação exata do ZimaOS. Considere “macvtap” a melhor explicação técnica para o isolamento do anfitrião observado, a menos que a documentação atual da IceWhale confirme explicitamente o backend.