Om en ZimaOS-VM som använder ”Bridge to eth0” får en vanlig IP-adress på det lokala nätverket och kan nå andra enheter i nätverket, men inte själva ZimaOS-värden, stämmer beteendet med det välkända macvtap-mönstret för värdisolering. I den ursprungliga tråden återställde en växling av VM:en till NAT omedelbart kommunikationen mellan VM och värd.
Tråden innehöll dock ingen bekräftelse från IceWhale på att ZimaOS definitivt implementerar detta alternativ med libvirt macvtap. Den korrekta formuleringen är därför symtombaserad: beteendet liknar macvtap-isolering, snarare än att hävda att den interna implementeringen är ett dokumenterat faktum.
Symtombilden är mycket specifik
- VM:en får en DHCP-adress på det fysiska lokala nätverket.
- VM:en kan nå routrar och andra enheter i det lokala nätverket.
- VM:en kan inte använda ARP mot eller ansluta till ZimaOS-värdens IP-adress.
- NAT-läge återställer åtkomsten till tjänster som körs på värden.
Detta skiljer sig från en VM som inte har något nätverk alls. Problemet påverkar främst arbetsflöden där gästen måste anropa en tjänst som är direkt bunden till ZimaOS-värden.
Varför detta liknar macvtap
Libvirt dokumenterar i sin guide om macvtap-isolering av värden samma mönster: en gäst som använder ett direkt-/macvtap-gränssnitt kan nå det externa nätverket men kan inte kommunicera direkt med sin virtualiseringsvärd.
Den aktuella referensen för libvirts nätverksformat skiljer också mellan en befintlig brygga på värden och en direktanslutning med macvtap, och beskriver macvtaps begränsning för kommunikation mellan värd och gäst.
Använd NAT när VM:en måste nå tjänster på ZimaOS-värden
I community-testet var NAT-läge den verifierade lösningen. Om en omvänd proxy i VM:en bara behöver utgående åtkomst till en tjänst på ZimaOS-värden kan NAT vara enklare än att tvinga fram ett LAN-bryggat gränssnitt.
Om gästen dessutom behöver en förstklassig LAN-adress är ett andra VM-gränssnitt på ett virtuellt nätverk som kan nå värden ett vanligt libvirt-mönster, men huruvida ZVM exponerar detta på ett smidigt sätt beror på den aktuella versionen av ZimaOS och dess användargränssnitt.
Utforma den omvända proxyn med hänsyn till nätverksgränsen
Om Caddy eller Nginx körs i en VM medan Home Assistant eller en annan tjänst körs direkt på ZimaOS-värden bör du verifiera att värden kan nås innan du lägger tid på TLS- eller proxykonfiguration. ZimaOS-guiden för omvänd proxy är användbar när grundläggande Layer 3-anslutning fungerar.
För allmän konfiguration av gränssnitt och IP-adresser erbjuder ZimaOS guide för enhetsanslutning en separat grund.
Slutsats
Tråden verifierar nätverkssymtomet och NAT-lösningen. Den verifierar inte den exakta implementeringen i ZimaOS. Betrakta ”macvtap” som den bästa tekniska förklaringen till den observerade värdisoleringen, såvida inte aktuell dokumentation från IceWhale uttryckligen bekräftar vilken backend som används.
