「Bridge to eth0」を使用する ZimaOS VM が通常の LAN IP を取得し、他の LAN デバイスには接続できる一方で、ZimaOS ホスト自体には接続できない場合、その挙動はよく知られている macvtap のホスト分離パターンと一致します。元のスレッドでは、VM を NAT に切り替えることで、VM からホストへの接続が直ちに回復しました。
ただし、そのスレッドには、ZimaOS がこのオプションを libvirt の macvtap で確実に実装しているという IceWhale の確認はありませんでした。したがって、正確な表現は症状に基づくものにすべきです。内部実装を文書化された事実として断定するのではなく、macvtap の分離に似た挙動だと説明します。
症状のパターンは非常に特徴的
- VM が物理 LAN 上の DHCP アドレスを取得する。
- VM からルーターや他の LAN デバイスに接続できる。
- VM から ZimaOS ホストの IP に対して ARP を実行したり、接続したりできない。
- NAT モードにすると、ホスト上で実行されているサービスにアクセスできるようになる。
これは、VM にネットワーク接続がまったくない場合とは異なります。主に、ゲストから ZimaOS ホストに直接バインドされたサービスを呼び出す必要があるワークフローに影響します。
macvtap に見える理由
libvirt のmacvtap ホスト分離ガイドには、同じパターンが記載されています。ダイレクト/macvtap インターフェースを使用するゲストは外部ネットワークには接続できますが、仮想化ホストとは直接通信できません。
現在のlibvirt ネットワーク形式リファレンスでも、既存のホストブリッジと macvtap のダイレクト接続が区別されており、macvtap ではホストからゲストへの接続に制限があることが説明されています。
VM から ZimaOS ホストのサービスに接続する必要がある場合は NAT を使用する
コミュニティでのテストでは、NAT モードが検証済みの回避策でした。VM 内のリバースプロキシが ZimaOS ホスト上のサービスへのアウトバウンドアクセスだけを必要とする場合、LAN ブリッジインターフェースを無理に使用するよりも NAT の方が簡単な場合があります。
ゲストにも正式な LAN アドレスが必要な場合は、ホストから到達可能な仮想ネットワーク上に VM の 2 つ目のインターフェースを接続する方法が、libvirt では一般的な構成です。ただし、ZVM でこの構成を適切に公開できるかどうかは、現在の ZimaOS の UI とバージョンによって異なります。
ネットワーク境界を考慮してリバースプロキシを設計する
Home Assistant や別のサービスが ZimaOS ホスト上で直接実行されている一方、Caddy や Nginx が VM 内で動作している場合は、TLS やプロキシの設定に時間をかける前に、ホストへの到達性を確認してください。基本的なレイヤー 3 接続が機能した後は、ZimaOS リバースプロキシガイドが役立ちます。
一般的なインターフェースと IP の設定については、ZimaOS デバイス接続ガイドで別途基本事項を確認できます。
結論
このスレッドで確認されているのは、ネットワークの症状と NAT による回避策です。ZimaOS の正確な実装までは確認されていません。現在の IceWhale のドキュメントでバックエンドが明示的に確認されない限り、「macvtap」は観測されたホスト分離に対する最も妥当な技術的説明として扱ってください。
