Warum ZVM im LAN funktionieren, aber über einen Tunnel fehlschlagen kann
Der Community-Fall betraf eine virtuelle ZVM-Maschine, die über das lokale Netzwerk korrekt angezeigt wurde, aber nicht über DDNS oder einen Cloudflare Tunnel. Im Thread wurde vermutet, dass die ZVM-Konsole neben der anfänglichen Webseite zusätzlichen Datenverkehr benötigt. Spätere Antworten erwähnten WireGuard und TCP-Passthrough auf Port 5700, der Thread bestätigt jedoch keine universelle Lösung für jede ZimaOS-Version.
Beginnen Sie bei der aktuellen Architektur für den Remotezugriff mit der aktuellen Konnektivitätsseite von Zima Client und dem aktuellen Leitfaden zum Remotezugriff mit Zima Client, bevor Sie einen öffentlichen Tunnel hinzufügen.
DDNS und Cloudflare Tunnel lösen unterschiedliche Ebenen
DDNS ordnet lediglich einen Hostnamen einer IP-Adresse zu. Cloudflare Tunnel proxied unterstützte Anwendungsprotokolle über cloudflared. Keines von beiden versteht automatisch jedes Mehrport- oder interaktive Konsolenprotokoll, das von einer VM-Verwaltungsoberfläche verwendet wird.
Die aktuelle Protokolldokumentation von Cloudflare besagt, dass TCP-Dienste für veröffentlichte Anwendungen über WebSocket gestreamt werden und für den Zugriff außerhalb von HTTP clientseitig cloudflared benötigen. Siehe die Protokolldokumentation von Cloudflare Tunnel und die aktuelle FAQ zu Cloudflare Tunnel.
Den ZVM-Pfad diagnostizieren, bevor Sie Ports ändern
- Bestätigen Sie, dass ZVM im LAN vollständig funktioniert.
- Öffnen Sie die Entwicklertools des Browsers und ermitteln Sie, welche WebSocket- oder sekundären Anfragen bei Verwendung des Tunnels fehlschlagen.
- Vergleichen Sie die Zielhostnamen und Ports zwischen der funktionierenden LAN-Sitzung und der Remote-Sitzung.
- Gehen Sie nicht davon aus, dass Port 5700 ausreicht, es sei denn, der aktuelle ZVM-Build verwendet ihn tatsächlich für Ihren Konsolenpfad.
- Testen Sie einen Ansatz über ein privates Netzwerk, etwa ZimaClient, WireGuard oder ein anderes unterstütztes Overlay, um festzustellen, ob der vollständige private Dienst ohne Protokollübersetzung funktioniert.
Wann TCP-Passthrough helfen kann
Eine Community-Antwort schlug NGINX Stream TCP-Passthrough für Port 5700 vor. Betrachten Sie dies als Community-Workaround und nicht als offizielle ZVM-Netzwerkspezifikation. Es kann nur dann nützlich sein, wenn Sie überprüft haben, dass der benötigte Konsolenverkehr über diesen Port als reines TCP übertragen wird und Ihre Authentifizierungsgrenze sicher bleibt.
Sicherheitsgrenze
Die Veröffentlichung einer VM-Konsole ist sensibler als die Veröffentlichung einer statischen Webseite. Bevorzugen Sie für Administrationsoberflächen ein privates Netzwerk, verlangen Sie auf jeder Ebene eine Authentifizierung und vermeiden Sie es, Verwaltungsports direkt dem öffentlichen Internet auszusetzen.
Die aktuelle offizielle Dokumentation zum Remotezugriff auf ZimaOS beschreibt integrierte und standardisierte Protokolloptionen für den Remotezugriff.
FAQ
Warum startet die VM, obwohl die Konsole nicht angezeigt wird?
Die Verwaltungsanfrage und der interaktive Konsolentransport können unterschiedliche Anfragen oder Kanäle verwenden. Der VM-Prozess kann erfolgreich starten, während der Browser den Darstellungspfad nicht herstellen kann.
Wird ZVM durch die Weiterleitung von Port 5700 immer repariert?
Nein. Der Community-Thread enthält einen erfolglosen Versuch mit der Weiterleitung von Port 5700. Überprüfen Sie daher den aktuellen Datenverkehr, anstatt von einem festen Port auszugehen.
Reicht DDNS für den Remotezugriff auf ZVM aus?
Nein. DDNS stellt lediglich die Namensauflösung bereit. Sie benötigen weiterhin einen sicheren und protokollkompatiblen Pfad zur VM-Konsole.
