“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 호스트 격리 가이드는 동일한 패턴을 설명합니다. direct/macvtap 인터페이스를 사용하는 게스트는 외부 네트워크에 연결할 수 있지만 가상화 호스트와 직접 통신할 수 없습니다.
현재 libvirt 네트워크 형식 참조 문서도 기존 호스트 브리지와 macvtap 직접 연결을 구분하며 macvtap의 호스트-게스트 연결 제한을 설명합니다.
VM이 ZimaOS 호스트 서비스에 연결해야 한다면 NAT를 사용하세요
커뮤니티 테스트에서는 NAT 모드가 검증된 해결 방법이었습니다. VM 내부의 리버스 프록시가 ZimaOS 호스트의 서비스에 아웃바운드로 연결하기만 하면 된다면, LAN 브리지 인터페이스를 강제로 설정하는 것보다 NAT가 더 간단할 수 있습니다.
게스트에 완전한 LAN 주소도 필요하다면, 호스트에서 연결할 수 있는 가상 네트워크에 두 번째 VM 인터페이스를 추가하는 것이 일반적인 libvirt 구성 방식입니다. 다만 ZVM에서 이 기능을 깔끔하게 제공하는지는 현재 ZimaOS UI 및 버전에 따라 달라집니다.
네트워크 경계를 기준으로 리버스 프록시를 설계하세요
Home Assistant 또는 다른 서비스가 ZimaOS 호스트에서 직접 실행되고 Caddy나 Nginx가 VM에서 실행되는 경우, TLS나 프록시 구성에 시간을 들이기 전에 호스트 연결 가능 여부를 확인하세요. 기본적인 Layer-3 연결이 작동한 후에는 ZimaOS 리버스 프록시 가이드가 유용합니다.
일반적인 인터페이스 및 IP 구성은 ZimaOS 장치 연결 가이드에서 별도의 기본 정보를 확인할 수 있습니다.
결론
해당 스레드는 네트워크 증상과 NAT 해결 방법을 검증합니다. 하지만 정확한 ZimaOS 구현 방식까지 검증한 것은 아닙니다. 현재 IceWhale 문서에서 백엔드를 명시적으로 확인해 주기 전까지는 “macvtap”을 관찰된 호스트 격자를 설명하는 가장 타당한 기술적 해석으로 보아야 합니다.
