Servidor de escritorio remoto Linux: configuración de X11VNC y del daemon RustDesk

Estás intentando permitir que otras personas (o tú mismo) se conecten a un escritorio Linux de forma fiable, segura y sin pasar por servicios propietarios costosos — y los manuales que encontraste son demasiado vagos o están escritos para usuarios de GUI. Esta guía muestra dos enfoques prácticos del lado del servidor para un servidor de escritorio remoto Linux: una configuración probada de X11VNC para exponer directamente una sesión X, y un daemon RustDesk autohospedado (hbbs/hbbr) para travesía de NAT y relay modernos — con comandos reales, unidades systemd, ejemplos en Docker y pasos concretos de hardening.

¿Por qué ejecutar un servidor de escritorio remoto en Linux? Árbol de decisión rápido

Antes de entrar en comandos: elige el modelo que se ajuste a tus necesidades.

• Si necesitas acceso directo a la sesión X física en una máquina (soportando al usuario conectado, el estado de la sesión local y múltiples monitores), X11VNC es la herramienta más simple del lado del servidor.
• Si quieres un modelo cliente/servidor que soporte travesía de NAT, servidores de ID, relays y clientes multiplataforma más sencillos — y deseas autohospedar esos componentes de servidor — ejecuta los daemon(s) hbbs/hbbr de RustDesk.
• Si solo necesitas un túnel rápido a una sola máquina para soporte puntual, un túnel SSH o usar un servicio alojado puede ser más rápido. Consulta también nuestra guía sobre escritorio remoto autohospedado para estrategia y compensaciones.

Nota: productos comerciales como TeamViewer y AnyDesk suelen ganar en pura conveniencia (travesía de NAT automática y códecs optimizados listos para usar). Son opciones razonables si necesitas confiabilidad plug-and-play y soporte comercial; consulta nuestra comparación de funcionalidades en rustdesk-vs-anydesk.

1) X11VNC: un servidor de escritorio remoto Linux mínimo que expone la sesión X física

X11VNC se conecta a un servidor X existente y sirve el escritorio actual. No es un escritorio virtual separado: refleja la GUI registrada localmente. Eso lo hace excelente para soporte remoto y administración cuando quieres interactuar con la misma sesión que ve un usuario local.

Requisitos y versiones recomendadas

• Funciona en escritorios basados en X11. Para Wayland, usa APIs remotas específicas del compositor o un enfoque distinto.
• Instala x11vnc >= 0.9.16 (0.9.16+ incluye características modernas y mejoras de estabilidad).
• Asegúrate de tener un display manager (gdm/lightdm/sddm) o una sesión X ejecutándose en :0.

Instalación en Debian/Ubuntu (ejemplo):

sudo apt update
sudo apt install -y x11vnc xauth

Crea un archivo de contraseña (guárdalo de forma segura):

sudo x11vnc -storepasswd /etc/x11vnc.pass
sudo chown root:root /etc/x11vnc.pass
sudo chmod 600 /etc/x11vnc.pass

Unidad systemd simple para autoarrancar en :0 (colócala en /etc/systemd/system/x11vnc.service):

[Unit]
Description=x11vnc - VNC server for :0
After=display-manager.service

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pass -rfbport 5900 -shared -ncache 10
User=root
Restart=on-failure

[Install]
WantedBy=graphical.target

Habilitar e iniciar:

sudo systemctl daemon-reload
sudo systemctl enable --now x11vnc.service
sudo systemctl status x11vnc.service

Notas de seguridad para X11VNC

• No expongas el puerto TCP/5900 directamente a Internet sin protecciones adicionales. La autenticación de VNC está bien para uso en LAN, pero debe considerarse débil en redes públicas.
• Prefiere un túnel SSH para acceso remoto: ssh -L 5900:localhost:5900 user@your-server y luego conecta un cliente VNC a localhost:5900.
• Si necesitas TLS directo, usa stunnel o una VPN. O coloca VNC detrás de un firewall adecuado y exige acceso por VPN.

Consejos de rendimiento

• Usa -ncache 10 para reducir picos de ancho de banda cuando el contenido del escritorio cambia rápidamente.
• Si ves CPU alta en enlaces de 1–2 Mbps, reduce la profundidad de color o usa flags de compresión (x11vnc soporta -compresslevel y -quality). Experimenta — menor calidad suele dar mejor respuesta percibida.

2) RustDesk daemon: servidor de ID y relay autohospedado para acceso remoto moderno

RustDesk ofrece un cliente que puede usar un servidor de ID central (hbbs) y un relay (hbbr) para conectar pares incluso detrás de NAT. Ejecutar tus propios hbbs/hbbr te da control total sobre IDs y relays — importante si quieres evitar servidores de terceros. Este es el despliegue del lado servidor al que la mayoría se refiere cuando pide un servidor de escritorio remoto autohospedado en Linux.

¿Por qué ejecutar hbbs/hbbr en lugar de un solo binario? Hbbs es el servidor de ID (autenticación, asignación), hbbr es el servidor relay (relay TCP/UDP para media cuando falla el P2P directo). Ambos son livianos y suelen ejecutarse en Docker.

Versiones recomendadas: usa los componentes de servidor de RustDesk 1.1.9+ (o la etiqueta estable más reciente al desplegar). Revisa las notas de la release del proyecto RustDesk antes de pasar a producción.

Ejemplo de Docker Compose para hbbs + hbbr (mínimo)

version: '3.3'
services:
  hbbs:
    image: rustdesk/rustdesk-server:1.1.9
    container_name: rustdesk_hbbs
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"  # hbbs TCP (ID server)
    environment:
      - RUST_LOG=info
    volumes:
      - ./data/hbbs:/data

  hbbr:
    image: rustdesk/rustdesk-server:1.1.9
    container_name: rustdesk_hbbr
    restart: unless-stopped
    ports:
      - "21116:21116/tcp"  # hbbr TCP (relay)
      - "21116:21116/udp"  # hbbr UDP for hole punching/relay
    environment:
      - RUST_LOG=info
    volumes:
      - ./data/hbbr:/data

Notas sobre puertos y NAT

• Los puertos por defecto de RustDesk que se suelen mapear son 21115 (hbbs ID server) y 21116 (hbbr relay). UDP es útil para la travesía de NAT; abre tanto TCP como UDP cuando sea posible.
• Mantén el servidor en una IP pública o en un host con IP/DNS estática. Usa un registro A/AAAA para el nombre de host que configures en los clientes.

Configuración del lado del cliente

Apunta el cliente RustDesk al hostname de tu hbbs y habilita el relay según sea necesario. Puedes forzar el uso de relay por privacidad o permitir peer-to-peer si ambos clientes pueden hacer punch-through al NAT. La UI de configuración del cliente acepta el hostname y puerto de tu servidor (p. ej., server.example.com:21115).

Asegurando un despliegue autohospedado de RustDesk (hbbs/hbbr)

El tráfico por defecto de RustDesk entre pares está cifrado, pero los componentes de servidor se encargan de la autenticación y coordinación. Considera estos pasos de hardening:

• Ejecuta hbbs/hbbr detrás de un firewall y abre solo los puertos necesarios (21115 TCP, 21116 TCP/UDP). Usa UFW o firewall-cmd; ejemplo: sudo ufw allow 21115/tcp; sudo ufw allow 21116/tcp; sudo ufw allow 21116/udp.
• Usa TLS/HTTPS para cualquier interfaz de administración web que añadas. Si terminas TLS en un reverse proxy (nginx/caddy), mantiene el backend aislado.
• Monitorea logs y uso de recursos. Los componentes de RustDesk son livianos, pero querrás vigilar conteos de conexiones y ancho de banda de relay.
• Considera rate-limiting y fail2ban en el host si observas intentos de fuerza bruta contra el puerto hbbs.

Cuándo elegir RustDesk vs X11VNC

• Elige RustDesk cuando necesites soporte de clientes multiplataforma (Windows/Mac/Linux/Android/iOS), travesía de NAT y un ID/relay autohospedado único para muchos endpoints. Es una solución moderna para flotas distribuidas.
• Elige X11VNC cuando estés atendiendo máquinas de escritorio específicas y necesites interactuar con la sesión X local (por ejemplo, para troubleshooting del usuario conectado o problemas de arranque gráfico).

Notas prácticas de producción y afinamiento de rendimiento

Ancho de banda y CPU: espera que sesiones remotas directas consuman entre 1–5 Mbps para tareas de oficina típicas con códecs comprimidos; compartir pantalla con video o juegos producirá picos mucho mayores. Si alojas tu propio relay (hbbr), presupuesta ancho de banda para relay: 100 sesiones concurrentes a 2 Mbps = ~200 Mbps de capacidad continua.

Monitoreo y autoescalado: para organizaciones grandes, ejecuta hbbs detrás de un pequeño proxy HA o balanceador de carga, y despliega múltiples relays hbbr distribuidos por regiones. Usa orquestación de contenedores estándar (Docker Swarm o Kubernetes) si necesitas autoescalado; de lo contrario, una única VM relay potente es suficiente para equipos pequeños.

Registro y solución de problemas

• Los logs de x11vnc aparecen en el journal de systemd: sudo journalctl -u x11vnc.service
• Contenedores RustDesk: docker logs rustdesk_hbbs y docker logs rustdesk_hbbr para errores de arranque. Comprueba la alcanzabilidad de puertos con ss o netstat y prueba UDP/TCP desde un cliente remoto.
• Si fallan las conexiones directas, confirma que UDP no esté siendo bloqueado por NATs intermedios o firewalls; muchos carriers bloquean rangos UDP poco comunes.

Comparación de seguridad y visión franca sobre proveedores

Si la seguridad y la privacidad son tus prioridades, autohospedar hbbs/hbbr te da control sobre metadatos y puntos de relay. Sin embargo, proveedores propietarios como TeamViewer o AnyDesk pueden ofrecer mejor travesía de NAT lista para usar, códecs propietarios con menores tasas de bits para enlaces pobres y soporte/SLAs empresariales. Pueden ser mejores si necesitas soporte comercial 24/7 y onboarding para usuarios no técnicos — pero esa conveniencia tiene un costo. Consulta anydesk-pricing-explained para diferencias de precio y compensaciones.

Lista de verificación práctica antes de poner en producción

1. Decide qué modelo te conviene (X11VNC para sesiones físicas vs RustDesk para acceso remoto basado en ID/relay).
2. Endurece el servidor: firewall, solo claves SSH, rate-limiting con fail2ban y TLS donde proceda.
3. Prueba desde fuera de tu red: verifica comportamiento de relay, latencia y conmutación por error.
4. Configura monitoreo (logs, ancho de banda, reinicios de procesos) y una política de alertas para incidencias.

Lecturas adicionales y recursos internos

Si estás evaluando opciones autohospedadas más amplias y sus compensaciones, lee nuestra guía autohospedada en /self-hosted-remote-desktop. Para una comparación de funcionalidades entre RustDesk y opciones comerciales, ve a /rustdesk-vs-anydesk.

Notas prácticas finales

Ambos enfoques son mantenibles, pero resuelven problemas ligeramente distintos. X11VNC es simple y predecible para escritorios individuales; los daemon de RustDesk escalan mejor para flotas y manejan la travesía de NAT con más elegancia cuando están configurados correctamente. En todos los casos, nunca expongas VNC sin cifrar directamente a Internet — usa siempre túneles SSH, VPNs o un relay correctamente endurecido.

¿Listo para probarlo? Descarga Tenvo (godeskflow) clients o consulta nuestra documentación de servidor en /download — y si necesitas opciones empresariales o precios, revisa /pricing. Despliega una instancia de prueba, ejercita tus reglas de firewall y valida el comportamiento del cliente antes de desplegar a los usuarios.