Servidor remoto Linux: configuración X11VNC y RustDesk

Estás intentando administrar o dar soporte a máquinas Linux de forma remota y estás cansado de soluciones ad hoc frágiles — SSH para acceso al shell, copiar archivos grandes manualmente o enviar un enlace de TeamViewer cada vez. Si quieres un escritorio remoto persistente del lado del servidor en Linux que arranque en el boot, sobreviva a reinicios y pueda ser autoalojado bajo tu control, este tutorial explica dos enfoques prácticos del lado del servidor: X11VNC para sesiones clásicas X11 y el daemon del servidor RustDesk para una opción moderna de rendezvous/relay autoalojada.

Cuándo ejecutar un servidor de escritorio remoto en Linux (y por qué)

Lista rápida para decidir si tiene sentido un escritorio remoto del lado del servidor:

• Necesitas acceso sin monitor o desatendido a una máquina (servidores de laboratorio, escritorios de oficina, kioscos).
• Quieres un único endpoint siempre activo al que puedas conectarte sin pedirle a alguien que inicie un cliente primero.
• Prefieres autoalojar (sin nube de terceros) o quieres un relay local para evitar exponer puertos RDP/VNC directamente.
• Quieres combinar el acceso VNC clásico de X11 con la travesía de NAT/relay moderna para comodidad del cliente.

X11VNC es un demonio VNC pequeño y maduro que exporta lo que esté en el display X11 (comúnmente :0). Los componentes servidor de RustDesk (hbbs + hbbr) proveen el rendezvous y el relay opcional para conexiones peer-to-peer — útil cuando los clientes están detrás de NAT. Ambos pueden coexistir: X11VNC te da un endpoint VNC siempre activo y RustDesk te da una forma gestionada para que los clientes remotos encuentren tu host sin hacer port-forwarding.

Opción A — X11VNC: acceso X11 estable, sencillo y del lado del servidor

Usa X11VNC cuando tus máquinas ejecuten un escritorio basado en X11 y quieras un servidor VNC sencillo que arranque al iniciar el sistema. X11VNC está probado en producción (release estable común: x11vnc 0.9.16 en muchos repositorios) e integra bien con systemd.

Instalar y asegurar x11vnc

En Debian/Ubuntu:

sudo apt update
sudo apt install -y x11vnc

Crea un archivo de contraseña (usa una frase de paso fuerte). Reemplaza 'remote' por el propietario del directorio home del usuario remoto.

sudo -u remote mkdir -p /home/remote/.vnc
sudo -u remote x11vnc -storepasswd /home/remote/.vnc/passwd
sudo chown -R remote:remote /home/remote/.vnc

Encuentra el archivo Xauthority correcto para tu display manager. Ubicaciones comunes:

• LightDM: /var/run/lightdm/root/:0
• GDM (GNOME): /run/user/1000/gdm/Xauthority or check /home//.Xauthority

Inicia x11vnc manualmente una vez para validar:

sudo -u remote x11vnc -display :0 -auth /home/remote/.Xauthority -rfbauth /home/remote/.vnc/passwd -forever -shared -noxdamage -o /var/log/x11vnc.log

Unidad systemd para un servicio siempre activo

Coloca este archivo en /etc/systemd/system/x11vnc.service — edita User, Group y la ruta de -auth para que coincidan con tu distro/display manager.

[Unit]
Description=x11vnc server for display :0
After=graphical.target

[Service]
Type=simple
User=remote
Group=remote
ExecStart=/usr/bin/x11vnc -display :0 -auth /home/remote/.Xauthority -rfbauth /home/remote/.vnc/passwd -forever -shared -noxdamage -repeat -o /var/log/x11vnc.log
Restart=on-failure

[Install]
WantedBy=graphical.target

Habilitar e iniciar:

sudo systemctl daemon-reload
sudo systemctl enable --now x11vnc.service
sudo journalctl -u x11vnc -f

Consideraciones de red y seguridad

VNC por defecto no está cifrado. Opciones para reforzar un endpoint VNC del lado del servidor:

• Vincular a localhost y requerir túnel SSH: ejecuta x11vnc con -rfbport 5901 y usa systemd para que solo escuche en 127.0.0.1, luego SSH -L 5901:localhost:5901.
• Usar una VPN para acceder a la LAN del host.
• Limitar el acceso con un firewall (ejemplo de ufw abajo).
• Si necesitas clientes remotos directos sin SSH, pon VNC detrás de un proxy TLS con stunnel/NGINX (añade CPU y complejidad).

# Basic UFW rule to allow local-network VNC only
sudo ufw allow from 192.168.0.0/16 to any port 5900 proto tcp
# Or bind to localhost and tunnel via SSH for remote access

Notas: X11VNC requiere una sesión X11. En Wayland (GNOME en algunas distros) usa servidores compatibles con Wayland (e.g., wayvnc) o el escritorio incorporado para escritorio remoto (a menudo RDP).

Opción B — daemon del servidor RustDesk: rendezvous y relay autoalojados

RustDesk te permite autoalojar el signaling (hbbs) y el servidor de relay (hbbr) para que los clientes encuentren y alcancen tus hosts sin exponer puertos VNC/RDP sin filtrar. Si ya ejecutas X11VNC para la sesión de escritorio, puedes anteponerlo con RustDesk para travesía de NAT y una experiencia de cliente más simple. Los componentes del servidor RustDesk suelen empaquetarse como imágenes docker; revisa las releases del proyecto — ejemplos de tags de servidor incluyen v1.2.0 (verifica el tag actual en el repo de RustDesk).

Ejemplo simple con Docker Compose

Este compose levanta hbbs (rendezvous) y hbbr (relay opcional). Los puertos mostrados son defaults comunes usados en la documentación comunitaria (ajusta si el upstream cambia puertos).

version: '3.7'
services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbs
    restart: unless-stopped
    ports:
      - '21112:21112/tcp'   # rendezvous
    environment:
      - HBBS_KEY=your_secret_key_here

  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbr
    restart: unless-stopped
    ports:
      - '21113:21113/udp'   # relay

Notas:

• Reemplaza HBBS_KEY (u otras env vars según las instrucciones actuales de RustDesk) por un valor seguro.
• Las imágenes oficiales y los nombres de variables de entorno de RustDesk cambian entre releases — consulta el repo del servidor de RustDesk antes de producción.

Conexión de clientes

En el lado cliente (app RustDesk de escritorio/móvil), apunta el cliente a la dirección de tu servidor hbbs (nombre DNS o IP pública): p. ej., 1.2.3.4:21112. Si el relay hbbr está disponible y hace falta, el cliente lo usará para pasar tráfico cuando falle la conexión directa (P2P). Luego puedes configurar el cliente para controlar remotamente un agente RustDesk que se ejecute en el host o usar RustDesk como broker que se conecte a un servicio VNC existente en el host (para eso normalmente ejecutas el agente RustDesk en el host, que a su vez puede reenviar a la sesión X11VNC).

Alternativa con systemd en lugar de Docker

Si prefieres no usar Docker, compila los binarios de rustdesk-server siguiendo la documentación del proyecto e instálalos como servicios systemd (hbbs y hbbr). El empaquetado varía por release; el enfoque con Docker es la forma más rápida de poner un servidor reproducible en marcha.

Seguridad, travesía de NAT y cuándo evitar exponer puertos

Dos enfoques generales para evitar exponer puertos de escritorio directamente:

1. Mantener VNC/RDP ligado a localhost; requerir SSH/VPN para alcanzar el host. Esta es la opción más simple y auditable para entornos con un solo administrador.
2. Autoalojar un relay/rendezvous (RustDesk) y usar TLS + autenticación. Esto reduce los puertos abiertos en el host pero requiere ejecutar y asegurar los servidores de relay.

Fragmentos de firewall (UFW):

# Allow only SSH from your office and block the rest
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
sudo ufw deny 5900/tcp

# If running RustDesk server on the relay box (example)
sudo ufw allow 21112/tcp
sudo ufw allow 21113/udp

Lista práctica de seguridad:

• Usar autenticación fuerte para la cuenta del agente VNC o RustDesk.
• Rotar o proteger las claves del servidor (RustDesk HBBS key) y mantener las imágenes actualizadas.
• Usar IDS/monitorización para alertar sobre escaneos de puertos e intentos de acceso fallidos.
• Si requieres sesiones de escritorio cifradas, termina TLS en un reverse proxy (Nginx/Caddy) frente al relay y exige TLS 1.2+ y cifrados fuertes.

Consejos operativos, resolución de problemas y mantenimiento

Problemas comunes y soluciones:

• No se ve el escritorio por VNC: confirma que el display X es :0 (ps aux | grep X) y que x11vnc usa el archivo -auth correcto.
• El servicio no arranca en el boot: establece WantedBy en graphical.target y confirma que el display manager arranca antes que x11vnc.
• Los clientes RustDesk no alcanzan el servidor: confirma DNS y firewall; prueba con telnet/IP tools e inspecciona los logs de contenedores (docker-compose logs -f).
• Rendimiento pobre: habilita -noxdamage para x11vnc (menos tearing, menor CPU para algunas cargas) y considera ajustar compresión/encodings en el cliente cuando esté disponible.

Plan de mantenimiento:

• Aplica actualizaciones de seguridad del OS semanalmente. En Debian/Ubuntu puedes automatizar unattended-upgrades para parches menores.
• Haz seguimiento de los repos upstream de RustDesk o x11vnc para correcciones de seguridad. Si usas imágenes docker, programa una actualización de imágenes y un pipeline de redeploy.
• Haz backup de archivos de configuración y de cualquier certificado TLS; almacena las claves HBBS en un gestor de secretos si es posible.

Cuando una herramienta comercial o RDP puede ser la mejor opción

Compromisos honestos:

• TeamViewer / AnyDesk: ganan en facilidad de uso extrema para usuarios no técnicos, traversal de NAT universal y apps móviles pulidas. Si necesitas soporte instantáneo y sin operaciones para cientos de endpoints no técnicos, un SaaS comercial puede valer la pena. Ve nuestra comparación en rustdesk-vs-anydesk para detalles.
• RDP (Microsoft Remote Desktop): en servidores y escritorios Windows, RDP nativo suele dar mejor rendimiento y funciones (portapapeles, transferencia de archivos, sonido). Pero RDP expone una superficie de ataque mayor si no está detrás de VPN o un bastión.

Si tu objetivo principal es el autoalojamiento y la privacidad —y estás de acuerdo con un poco más de configuración inicial y mantenimiento continuo— la combinación X11VNC + RustDesk server es un enfoque sólido y práctico.

Lecturas adicionales y recursos internos

Si quieres evitar el port-forwarding por completo, lee nuestro walkthrough: Remote desktop without port forwarding. Para una visión de más alto nivel sobre desplegar tu propia solución, ve Self-hosted remote desktop guide. Para prácticas de hardening de seguridad, consulta Remote desktop security.

Finalmente, Tenvo está enfocado en tooling abierto y autoalojado para escritorio remoto — si quieres una alternativa cliente/servidor diseñada para autoalojamiento y uso multiplataforma, revisa nuestras páginas de descargas o precios para empezar: /download y /pricing. Describimos patrones de despliegue similares en otras publicaciones y mantenemos los ejemplos actualizados.

Si quieres ayuda con una distro específica, display manager o para afinar un arranque systemd para un entorno particular, dime la distro y el display manager (por ejemplo, Ubuntu 22.04 con GDM) y te daré una unidad adaptada y comandos de auth-path. Cuando estés listo, descarga Tenvo o intenta construir la pila descrita arriba — empieza en /download.