Por qué ZVM puede funcionar en la LAN, pero fallar a través de un túnel
El caso de la comunidad mostraba una máquina virtual de ZVM que se visualizaba correctamente a través de la red local, pero no mediante DDNS o Cloudflare Tunnel. En el hilo se sospechaba que la consola de ZVM depende de tráfico adicional más allá de la página web inicial. Respuestas posteriores mencionaron WireGuard y el reenvío TCP en el puerto 5700, pero el hilo no establece una solución universal para todas las versiones de ZimaOS.
Para conocer la arquitectura actual de acceso remoto, consulta primero la página de conectividad de Zima Client y la guía de acceso remoto de Zima Client antes de añadir un túnel público.
DDNS y Cloudflare Tunnel resuelven capas diferentes
DDNS solo asigna un nombre de host a una dirección IP. Cloudflare Tunnel actúa como proxy para los protocolos de aplicación compatibles mediante cloudflared. Ninguno entiende automáticamente todos los protocolos de consola interactivos o de varios puertos utilizados por una interfaz de gestión de máquinas virtuales.
La documentación actual de protocolos de Cloudflare indica que los servicios TCP se transmiten mediante WebSocket para las aplicaciones publicadas y requieren cloudflared en el lado del cliente para el acceso no HTTP. Consulta la documentación de protocolos de Cloudflare Tunnel y las preguntas frecuentes de Cloudflare Tunnel.
Diagnostica la ruta de ZVM antes de cambiar puertos
- Confirma que ZVM funciona completamente desde la LAN.
- Abre las herramientas de desarrollo del navegador e identifica los WebSocket o las solicitudes secundarias que fallan al utilizar el túnel.
- Compara los nombres de host y los puertos de destino entre la sesión funcional en la LAN y la sesión remota.
- No des por hecho que el puerto 5700 es suficiente, a menos que la compilación actual de ZVM realmente lo utilice para la ruta de tu consola.
- Prueba un enfoque de red privada, como ZimaClient, WireGuard u otra red superpuesta compatible, para comprobar si el servicio privado completo funciona sin traducción de protocolos.
Cuándo puede ayudar el reenvío TCP
Una respuesta de la comunidad sugirió utilizar el reenvío TCP de NGINX Stream para el puerto 5700. Considéralo una solución alternativa de la comunidad, no un contrato oficial de red de ZVM. Solo puede ser útil si has verificado que el tráfico de consola necesario es TCP sin más en ese puerto y que el perímetro de autenticación sigue siendo seguro.
Perímetro de seguridad
Publicar una consola de máquina virtual es más delicado que publicar una página web estática. Prefiere una red privada para las interfaces administrativas, exige autenticación en cada capa y evita exponer directamente los puertos de gestión a Internet público.
La documentación oficial actual sobre acceso remoto de ZimaOS describe las opciones integradas y de acceso remoto mediante protocolos estándar.
Preguntas frecuentes
¿Por qué se inicia la máquina virtual aunque la consola no se muestre?
La solicitud de gestión y el transporte de la consola interactiva pueden utilizar solicitudes o canales diferentes. El proceso de la máquina virtual puede iniciarse correctamente mientras el navegador no logra establecer la ruta de visualización.
¿El reenvío del puerto 5700 siempre solucionará ZVM?
No. El hilo de la comunidad incluye un intento fallido de reenvío del puerto 5700, así que verifica el tráfico actual en lugar de asumir que existe un único puerto fijo.
¿Es suficiente el DDNS para el acceso remoto a ZVM?
No. El DDNS solo proporciona resolución de nombres; aún necesitas una ruta segura y compatible con el protocolo hasta la consola de la máquina virtual.
