Dlaczego ZVM może działać w sieci LAN, ale nie działać przez tunel
W opisanym przypadku społeczności maszyna wirtualna ZVM wyświetlała się prawidłowo w sieci lokalnej, ale nie przez DDNS ani Cloudflare Tunnel. W wątku podejrzewano, że konsola ZVM wymaga dodatkowego ruchu poza początkową stroną internetową. W późniejszych odpowiedziach wspomniano o WireGuardzie i przekazywaniu TCP na porcie 5700, ale wątek nie potwierdza jednego uniwersalnego rozwiązania dla każdej wersji ZimaOS.
W przypadku obecnej architektury zdalnego dostępu najpierw zapoznaj się z aktualną stroną łączności Zima Client oraz przewodnikiem po zdalnym dostępie Zima Client, zanim dodasz publiczny tunel.
DDNS i Cloudflare Tunnel rozwiązują problemy na różnych warstwach
DDNS mapuje jedynie nazwę hosta na adres IP. Cloudflare Tunnel przekazuje obsługiwane protokoły aplikacyjne za pośrednictwem cloudflared. Żadne z tych rozwiązań nie rozumie automatycznie każdego wieloportowego ani interaktywnego protokołu konsoli używanego przez interfejs zarządzania maszynami wirtualnymi.
Aktualna dokumentacja protokołów Cloudflare wskazuje, że usługi TCP są przesyłane przez WebSocket dla opublikowanych aplikacji i wymagają cloudflared po stronie klienta w przypadku dostępu innego niż HTTP. Zobacz dokumentację protokołów Cloudflare Tunnel oraz aktualne FAQ Cloudflare Tunnel.
Zdiagnozuj ścieżkę ZVM przed zmianą portów
- Potwierdź, że ZVM działa w pełni z poziomu sieci LAN.
- Otwórz narzędzia deweloperskie przeglądarki i podczas korzystania z tunelu sprawdź, które połączenia WebSocket lub żądania dodatkowe kończą się niepowodzeniem.
- Porównaj nazwy hostów docelowych i porty między działającą sesją LAN a sesją zdalną.
- Nie zakładaj, że port 5700 wystarczy, chyba że aktualna kompilacja ZVM rzeczywiście używa go w ścieżce konsoli.
- Przetestuj podejście oparte na sieci prywatnej, takie jak ZimaClient, WireGuard lub inna obsługiwana sieć nakładkowa, aby sprawdzić, czy pełna usługa prywatna działa bez translacji protokołu.
Kiedy przekazywanie TCP może pomóc
W jednej z odpowiedzi społeczności zasugerowano przekazywanie TCP za pomocą NGINX Stream dla portu 5700. Traktuj to jako obejście zaproponowane przez społeczność, a nie oficjalną specyfikację sieciową ZVM. Może być przydatne tylko wtedy, gdy potwierdzisz, że wymagany ruch konsoli jest zwykłym ruchem TCP na tym porcie, a granica uwierzytelniania pozostaje bezpieczna.
Granica bezpieczeństwa
Udostępnienie konsoli maszyny wirtualnej jest bardziej wrażliwe niż udostępnienie statycznej strony internetowej. W przypadku interfejsów administracyjnych preferuj sieć prywatną, wymagaj uwierzytelniania na każdej warstwie i unikaj bezpośredniego wystawiania portów zarządzania do publicznego internetu.
Aktualna oficjalna dokumentacja zdalnego dostępu ZimaOS opisuje wbudowane opcje zdalnego dostępu oraz opcje oparte na standardowych protokołach.
FAQ
Dlaczego maszyna wirtualna uruchamia się, mimo że konsola się nie wyświetla?
Żądanie zarządzania i transport interaktywnej konsoli mogą korzystać z różnych żądań lub kanałów. Proces maszyny wirtualnej może uruchomić się prawidłowo, podczas gdy przeglądarka nie zdoła ustanowić ścieżki wyświetlania.
Czy przekierowanie portu 5700 zawsze naprawi ZVM?
Nie. Wątek społeczności zawiera przykład nieudanego przekierowania portu 5700, dlatego należy zweryfikować bieżący ruch zamiast zakładać istnienie jednego stałego portu.
Czy DDNS wystarczy do zdalnego korzystania z ZVM?
Nie. DDNS zapewnia jedynie rozwiązywanie nazw; nadal potrzebujesz bezpiecznej i zgodnej z protokołem ścieżki do konsoli maszyny wirtualnej.
