Si une machine virtuelle ZimaOS utilisant « Bridge to eth0 » reçoit une adresse IP LAN normale et peut communiquer avec d’autres appareils du réseau local, mais ne peut pas joindre l’hôte ZimaOS lui-même, ce comportement correspond au problème bien connu d’isolation de l’hôte associé à macvtap. Dans le fil d’origine, le passage de la machine virtuelle en mode NAT a immédiatement rétabli la connectivité entre la machine virtuelle et l’hôte.
Toutefois, le fil ne contenait aucune confirmation d’IceWhale indiquant que ZimaOS implémente effectivement cette option avec macvtap via libvirt. La formulation correcte doit donc se fonder sur les symptômes : le comportement ressemble à une isolation macvtap, plutôt que d’affirmer que l’implémentation interne est un fait documenté.
Les symptômes sont très caractéristiques
- La machine virtuelle reçoit une adresse DHCP sur le réseau local physique.
- La machine virtuelle peut joindre les routeurs et les autres appareils du réseau local.
- La machine virtuelle ne peut pas résoudre l’adresse ARP ni se connecter à l’adresse IP de l’hôte ZimaOS.
- Le mode NAT rétablit l’accès aux services exécutés sur l’hôte.
Cette situation diffère de celle d’une machine virtuelle totalement dépourvue de réseau. Elle concerne principalement les scénarios dans lesquels le système invité doit appeler un service lié directement à l’hôte ZimaOS.
Pourquoi cela ressemble à macvtap
Le guide de libvirt sur l’isolation de l’hôte avec macvtap décrit le même scénario : un invité utilisant une interface directe/macvtap peut accéder au réseau externe, mais ne peut pas communiquer directement avec son hôte de virtualisation.
La référence actuelle sur le format réseau de libvirt distingue également un pont hôte préexistant d’une connexion directe macvtap et mentionne la limitation des communications entre l’hôte et l’invité avec macvtap.
Utilisez le NAT lorsque la machine virtuelle doit accéder aux services de l’hôte ZimaOS
Lors du test effectué par la communauté, le mode NAT constituait la solution de contournement vérifiée. Si un proxy inverse exécuté dans la machine virtuelle a uniquement besoin d’un accès sortant à un service hébergé sur l’hôte ZimaOS, le NAT peut être plus simple que de forcer l’utilisation d’une interface pontée au réseau local.
Si l’invité a également besoin d’une adresse LAN dédiée, une deuxième interface réseau virtuelle sur un réseau virtuel accessible depuis l’hôte constitue un schéma courant avec libvirt. Toutefois, la possibilité de le configurer proprement dans ZVM dépend de l’interface et de la version actuelles de ZimaOS.
Concevez le proxy inverse en fonction de la limite réseau
Si Caddy ou Nginx s’exécute dans une machine virtuelle tandis que Home Assistant ou un autre service s’exécute directement sur l’hôte ZimaOS, vérifiez l’accessibilité de l’hôte avant de consacrer du temps à la configuration de TLS ou du proxy. Le guide du proxy inverse ZimaOS est utile une fois que la connectivité de couche 3 fonctionne correctement.
Pour la configuration générale des interfaces et des adresses IP, le guide de connexion des appareils ZimaOS fournit une base distincte.
En résumé
Le fil confirme les symptômes réseau et la solution de contournement via le NAT. Il ne confirme pas l’implémentation exacte de ZimaOS. Considérez « macvtap » comme la meilleure explication technique de l’isolation observée de l’hôte, à moins que la documentation actuelle d’IceWhale ne confirme explicitement le backend utilisé.
