Gość ZVM może mieć prawidłowy adres w sieci LAN, a mimo to nie mieć dostępu do usług działających bezpośrednio na hoście ZimaOS. To był główny problem opisany w tym wątku. Przy ustawieniu maszyny wirtualnej Bridge to eth0 gość mógł działać w sieci LAN, ale nie miał trasy do hosta. Zima-Giorgio zalecił przełączenie maszyny wirtualnej na NAT, jeśli celem było połączenie z udziałami ZimaOS.
Źródło pokazuje również, że „trasa sieciowa” i „uprawnienia SMB” to osobne problemy. Później inny użytkownik przełączył maszynę na NAT i dotarł do okna logowania, ale nadal nie mógł uzyskać dostępu do udziału RAID przy użyciu kilku kont. Tego problemu z uwierzytelnianiem i pamięcią masową nie należy mylić z izolacją hosta występującą w trybie mostu.
Tryb mostu zapewniał maszynie wirtualnej normalny dostęp do sieci LAN
Pierwotny użytkownik wybrał Bridge to eth0, ponieważ chciał, aby maszyna wirtualna zachowywała się jak kolejne urządzenie w sieci lokalnej. W tym trybie maszyna mogła otrzymać adres LAN i komunikować się z innymi systemami w sieci lokalnej.
Brakowało wyłącznie ścieżki komunikacji między maszyną wirtualną a hostem ZimaOS.
Zima-Giorgio zalecił NAT w celu uzyskania dostępu do hosta
Zima-Giorgio z IceWhale polecił użytkownikowi wyłączyć maszynę wirtualną i zmienić tryb sieciowy z Bridge na NAT. W dalszej części rozmowy opisał to jako kompromis: NAT umożliwia dostęp do hosta, natomiast tryb mostu zapewnia dostęp do innych urządzeń w sieci LAN.
To oficjalna wskazówka pomocy technicznej z wątku źródłowego z 2025 roku, a nie ogólne stwierdzenie dotyczące każdej topologii libvirt.
Późniejsze doniesienia społeczności nadal wskazywały na izolację hosta przez macvtap
W maju i czerwcu 2026 roku w innym wątku społeczności opisano ten sam schemat: maszyna wirtualna działająca w trybie mostu otrzymywała prawidłowy adres IP z sieci LAN, mogła łączyć się z innymi urządzeniami w tej sieci, ale nie mogła wykonywać zapytań ARP ani łączyć się z hostem ZimaOS. Przełączenie na NAT natychmiast przywróciło łączność z hostem.
Użytkownicy podejrzewali, że ścieżka „Bridge to eth0” w ZVM jest zaimplementowana przy użyciu macvtap, którego zachowanie polegające na izolowaniu hosta jest dobrze znane. W publicznym wątku nie było potwierdzenia IceWhale dotyczącego dokładnego zaplecza technicznego, dlatego macvtap należy traktować jako mocne wyjaśnienie społeczności, a nie oficjalne twierdzenie na temat implementacji.
Problemy z logowaniem SMB dotyczą osobnej warstwy
Jeden z uczestników przełączył maszynę na NAT i w końcu uzyskał dostęp do okna logowania ZimaCube, ale konta SMB nadal działały niespójnie. Jego główne konto mogło przeglądać niektóre ścieżki hosta, lecz dostęp do RAID kończył się niepowodzeniem, a inne konta zwracały błędy uprawnień.
Gdy podstawowa łączność IP już działa, należy osobno sprawdzić konto udziału SMB i jego uprawnienia.
Aktualna dokumentacja ZimaOS opisuje udostępnianie Samba poszczególnym użytkownikom oraz uprawnienia tylko do odczytu lub odczytu i zapisu. Gdy maszyna wirtualna może połączyć się z serwerem, ale uwierzytelnianie lub dostęp nadal kończą się niepowodzeniem, skorzystaj z aktualnego modelu uprawnień Samba dla wielu użytkowników w ZimaOS.
Wpisy Ubuntu „Udostępnianie plików” i „Zdalne logowanie” nie używają tego samego protokołu
Użytkownik opisany w źródle zauważył, że Ubuntu wyświetlało „ZimaCube (File Sharing)” oraz „ZimaCube (Remote Login)”. W jego menedżerze haseł widniało również połączenie sftp:// dotyczące tej drugiej pozycji.
SFTP przez SSH i SMB to różne usługi. Pomyślne logowanie przez SFTP nie dowodzi, że uprawnienia SMB są prawidłowe, a udział SMB należy testować za pomocą adresu SMB lub przeglądarki udziałów sieciowych, a nie wpisu SSH.
Użytkownik społeczności zbudował obejście oparte na statycznych trasach w trybie mostu
Inny uczestnik pozostawił maszynę wirtualną w trybie mostu i użył trzeciego serwera Debiana jako routera między maszyną wirtualną a hostem, a następnie dodał statyczne trasy na obu urządzeniach końcowych. Zgłosił, że rozwiązanie działało, ale określił je jako „niezbyt eleganckie”.
Te polecenia routingu w systemie Linux były eksperymentem społeczności, a nie zalecanym przez IceWhale projektem ZVM. Dodatkowy router staje się również wąskim gardłem przepustowości i kolejnym punktem awarii.
Wybierz tryb sieciowy na podstawie rzeczywistej roli maszyny wirtualnej
- Maszyna wirtualna ma głównie korzystać z usług lub udziałów hostowanych przez ZimaOS: NAT jest pierwszym testem wspieranym przez źródło.
- Maszyna wirtualna ma głównie zachowywać się jak osobne urządzenie w sieci LAN: tryb mostu może zapewnić jej normalny adres LAN.
- Maszyna wirtualna potrzebuje dostępu zarówno do hosta, jak i do sieci LAN: dokładnie przetestuj aktualne wydanie ZVM; źródło historyczne pokazuje, że była to nierozwiązana luka.
Aktualne ustawienia sieciowe ZimaOS nie opisują procedury konfiguracji br0 dla ZVM
Aktualna publiczna dokumentacja sieciowa ZimaOS obejmuje interfejsy fizyczne, konfigurację adresu IP przez DHCP lub ręcznie oraz dostęp zdalny. Nie publikuje obsługiwanej procedury tworzenia niestandardowego mostu hosta przeznaczonego do obejścia izolacji hosta w ZVM.
Przed ręczną edycją tras hosta lub plików NetworkManager zapoznaj się z aktualnym modelem sieciowym ZimaOS.
Często zadawane pytania dotyczące dostępu ZVM do hosta
Czy NAT umożliwił maszynie wirtualnej ze źródła dostęp do hosta ZimaOS?
Tak. Użytkownicy zgłaszali, że zmiana na NAT usunęła problem braku trasy do hosta.
Czy NAT automatycznie naprawił uprawnienia SMB?
Nie. Jeden z użytkowników uzyskał dostęp do okna logowania, ale nadal miał osobne problemy z uprawnieniami do udziałów.
Czy obejście z użyciem routingu przez trzeci serwer było oficjalne?
Nie. Było to rozwiązanie społeczności przeznaczone dla użytkowników, którzy chcieli pozostać przy trybie mostu.
