Perché ZVM può funzionare sulla LAN ma non attraverso un tunnel
Il caso della community mostrava una macchina virtuale ZVM visualizzata correttamente sulla rete locale, ma non tramite DDNS o Cloudflare Tunnel. La discussione ipotizzava che la console ZVM dipendesse da traffico aggiuntivo oltre alla pagina web iniziale. Le risposte successive menzionavano WireGuard e il passthrough TCP sulla porta 5700, ma la discussione non stabilisce una soluzione universale per ogni versione di ZimaOS.
Per l'architettura di accesso remoto attuale, consulta innanzitutto la pagina sulla connettività di Zima Client e la guida all'accesso remoto di Zima Client prima di aggiungere un tunnel pubblico.
DDNS e Cloudflare Tunnel operano su livelli diversi
Il DDNS associa semplicemente un nome host a un indirizzo IP. Cloudflare Tunnel esegue il proxy dei protocolli applicativi supportati tramite cloudflared. Nessuno dei due comprende automaticamente ogni protocollo interattivo o a più porte utilizzato da un'interfaccia di gestione delle macchine virtuali.
La documentazione attuale dei protocolli Cloudflare indica che i servizi TCP vengono trasmessi tramite WebSocket per le applicazioni pubblicate e richiedono cloudflared lato client per l'accesso non HTTP. Consulta la documentazione sui protocolli di Cloudflare Tunnel e le FAQ di Cloudflare Tunnel.
Diagnostica il percorso ZVM prima di modificare le porte
- Verifica che ZVM funzioni completamente dalla LAN.
- Apri gli strumenti per sviluppatori del browser e individua le richieste WebSocket o secondarie che non vanno a buon fine quando usi il tunnel.
- Confronta i nomi host e le porte di destinazione tra la sessione LAN funzionante e la sessione remota.
- Non presumere che la porta 5700 sia sufficiente, a meno che la build ZVM attuale non la utilizzi effettivamente per il percorso della tua console.
- Prova un approccio basato su una rete privata, come ZimaClient, WireGuard o un'altra rete overlay supportata, per verificare se il servizio privato completo funziona senza traduzione dei protocolli.
Quando il passthrough TCP può essere utile
Una risposta della community suggeriva il passthrough TCP di NGINX Stream per la porta 5700. Consideralo un workaround della community, non un contratto ufficiale di rete ZVM. Può essere utile solo se hai verificato che il traffico della console necessario sia TCP puro su quella porta e che il perimetro di autenticazione rimanga sicuro.
Perimetro di sicurezza
Pubblicare una console di una macchina virtuale è più rischioso che pubblicare una pagina web statica. Preferisci una rete privata per le interfacce amministrative, richiedi l'autenticazione a ogni livello ed evita di esporre direttamente le porte di gestione su Internet.
La documentazione ufficiale attuale sull'accesso remoto di ZimaOS descrive le opzioni di accesso remoto integrate e basate su protocolli standard.
Domande frequenti
Perché la macchina virtuale si avvia anche se la console non viene visualizzata?
La richiesta di gestione e il trasporto della console interattiva possono utilizzare richieste o canali diversi. Il processo della macchina virtuale può avviarsi correttamente mentre il browser non riesce a stabilire il percorso di visualizzazione.
Il port forwarding della porta 5700 risolverà sempre il problema di ZVM?
No. La discussione della community include un tentativo non riuscito di inoltro della porta 5700, quindi verifica il traffico attuale invece di presumere l'esistenza di una porta fissa.
Il DDNS è sufficiente per usare ZVM da remoto?
No. Il DDNS fornisce solo la risoluzione dei nomi; serve comunque un percorso sicuro e compatibile con il protocollo per raggiungere la console della macchina virtuale.
