Community-Lösung

ZimaOS-VM-Bridge erreicht den Host nicht: macvtap oder 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.

Wenn eine ZimaOS-VM mit „Bridge to eth0“ eine normale LAN-IP-Adresse erhält und andere LAN-Geräte erreichen kann, aber nicht den ZimaOS-Host selbst, entspricht dieses Verhalten dem bekannten Macvtap-Muster der Host-Isolierung. Im ursprünglichen Thread stellte der Wechsel der VM zu NAT die Verbindung zwischen VM und Host sofort wieder her.

Der Thread enthielt jedoch keine Bestätigung von IceWhale, dass ZimaOS diese Option definitiv mit Libvirt-Macvtap implementiert. Die korrekte Formulierung sollte daher auf den Symptomen basieren: Das Verhalten ähnelt einer Macvtap-Isolierung, anstatt die interne Implementierung als dokumentierte Tatsache darzustellen.

Das Symptombild ist sehr spezifisch

  • Die VM erhält eine DHCP-Adresse im physischen LAN.
  • Die VM kann Router und andere LAN-Geräte erreichen.
  • Die VM kann die ZimaOS-Host-IP weder per ARP auflösen noch eine Verbindung zu ihr herstellen.
  • Der NAT-Modus stellt den Zugriff auf Dienste wieder her, die auf dem Host ausgeführt werden.

Das unterscheidet sich von einer VM, die überhaupt keine Netzwerkverbindung hat. Betroffen sind hauptsächlich Anwendungsfälle, bei denen der Gast einen direkt am ZimaOS-Host gebundenen Dienst aufrufen muss.

Warum dies nach Macvtap aussieht

Der Leitfaden zur Macvtap-Hostisolierung von Libvirt dokumentiert dasselbe Muster: Ein Gast, der eine direkte Macvtap-Schnittstelle verwendet, kann das externe Netzwerk erreichen, aber nicht direkt mit seinem Virtualisierungshost kommunizieren.

Die aktuelle Referenz zum Libvirt-Netzwerkformat unterscheidet außerdem zwischen einer bereits vorhandenen Host-Bridge und einer direkten Macvtap-Verbindung und weist auf die Einschränkung der Host-Gast-Kommunikation bei Macvtap hin.

NAT verwenden, wenn die VM ZimaOS-Hostdienste erreichen muss

Im Community-Test erwies sich der NAT-Modus als bestätigte Lösung. Wenn ein Reverse-Proxy innerhalb der VM lediglich ausgehend auf einen Dienst auf dem ZimaOS-Host zugreifen muss, kann NAT einfacher sein, als eine LAN-gebrückte Schnittstelle zu erzwingen.

Wenn der Gast zusätzlich eine vollwertige LAN-Adresse benötigt, ist eine zweite VM-Schnittstelle in einem vom Host erreichbaren virtuellen Netzwerk ein gängiges Libvirt-Muster. Ob ZVM dies sauber unterstützt, hängt jedoch von der aktuellen ZimaOS-Oberfläche und -Version ab.

Den Reverse-Proxy passend zur Netzwerkgrenze entwerfen

Wenn Caddy oder Nginx in einer VM läuft, während Home Assistant oder ein anderer Dienst direkt auf dem ZimaOS-Host ausgeführt wird, sollte die Erreichbarkeit des Hosts geprüft werden, bevor Zeit in TLS- oder Proxy-Konfiguration investiert wird. Der ZimaOS-Leitfaden für Reverse-Proxys ist hilfreich, sobald die grundlegende Layer-3-Konnektivität funktioniert.

Für die allgemeine Konfiguration von Schnittstellen und IP-Adressen bietet der ZimaOS-Leitfaden zur Geräteverbindung eine separate Grundlage.

Fazit

Der Thread bestätigt das Netzwerkverhalten und die NAT-Lösung. Die genaue Implementierung in ZimaOS wird dadurch jedoch nicht bestätigt. „Macvtap“ sollte als beste technische Erklärung für die beobachtete Host-Isolierung betrachtet werden, sofern die aktuelle Dokumentation von IceWhale das Backend nicht ausdrücklich bestätigt.