Configuración RustDesk autohospedado — guía completa Docker + TLS con Caddy

Estás intentando autohospedar RustDesk pero te topas con los mismos bloqueos: NAT y firewalls, componentes de servidor confusos y la duda de si necesitas TLS además del cifrado propio de RustDesk. Esta guía guía a un lector con perfil técnico a través de una instalación completa y reproducible de rustdesk autohospedado en un solo VPS — Docker Compose para hbbs/hbbr, y TLS en la entrada usando Caddy para que los clientes puedan conectarse por 443 desde redes restrictivas.

Qué construiremos y por qué

El objetivo: un rendezvous + relay de RustDesk en un único VPS que los clientes apunten por nombre DNS. Componentes en juego:

• rustdesk server components (hbbs and hbbr) ejecutándose en Docker — probado aquí con imágenes rustdesk-server v1.2.1.
• Caddy v2 (gestión de certificados vía Let's Encrypt) para ofrecer una puerta TLS en el puerto 443 y así permitir que los clientes lleguen al relay incluso cuando outbound 21115 esté bloqueado.
• Passthrough UDP opcional o relays adicionales para escalado (cubierto en notas).

¿Por qué hacer esto? El protocolo de RustDesk ya provee cifrado end-to-end para la sesión de escritorio, pero muchas redes solo permiten salida por 443/80. Terminar TLS en tu VPS (y dejar que Caddy obtenga y renueve certificados automáticamente) es una forma práctica de hacer el servicio accesible sin abrir puertos no estándar. Si solo quieres acceso LAN o controlar NAT con túneles inversos, ve nuestro artículo sobre remote-desktop-without-port-forwarding.

Requisitos y decisiones

Lo que usé mientras escribía esto:

• Ubuntu 22.04 LTS en un VPS público (1 vCPU / 2 GB RAM es suficiente para pruebas; para muchos clientes aumenta a 4+ CPU y monitorea CPU/RAM).
• Docker 24.x y Docker Compose v2 (sintaxis CLI de compose V2).
• rustdesk-server Docker image (tag v1.2.1 en esta guía) — ajusta si existen versiones estables más nuevas.
• Caddy v2.6+ (la ACME automática de Caddy hace que la renovación de certificados sea sencilla).
• Un registro DNS A como rustdesk.example.com apuntando a la IP pública del VPS, y puertos 80/443 permitidos (Caddy necesita 80/443 para validar).

Notas sobre cuándo un producto comercial alojado puede ser más apropiado: si necesitas SLA empresarial, auditoría avanzada de sesiones o soporte comercial, TeamViewer/AnyDesk pueden encajar mejor — consulta rustdesk-vs-anydesk y nuestras comparativas de precios. El autohospedaje es ideal si quieres control, menores costos recurrentes o evitar servidores de terceros.

Paso 1 — Desplegar el servidor rustdesk con Docker Compose

Crea un directorio de proyecto en el VPS y coloca el docker-compose.yml abajo. Este ejemplo expone los puertos típicos del servidor RustDesk en el host. Reemplaza variables de entorno y tags de imagen según tu entorno.

mkdir -p ~/rustdesk-server
cd ~/rustdesk-server
cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
  rustdesk-server:
    image: rustdesk/rustdesk-server:1.2.1
    container_name: rustdesk-server
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"   # rendezvous / TCP relay
      - "21115:21115/udp"   # optional UDP relay (if your image supports it)
      - "21116:21116/udp"   # additional UDP (some builds use multiple UDP ports)
    volumes:
      - ./data:/root/.config/rustdesk-server
    environment:
      - RUSTDESK_RELAY_IPV4=0.0.0.0
      - RUSTDESK_RELAY_PORT=21115
EOF

Inícialo:

docker compose up -d
# watch logs
docker compose logs -f rustdesk-server

Confirma que el contenedor arrancó y está escuchando en 21115. En tu VPS ejecuta:

ss -tuln | grep 21115

Si la imagen que usas expone puertos distintos o tiene un estilo de configuración diferente, consulta el README de esa imagen. Algunos operadores compilan hbbs/hbbr manualmente y usan puertos personalizados; adapta estos pasos según corresponda.

Paso 2 — Usar Caddy para añadir TLS al relay (443)

Hay dos patrones comunes para hacer RustDesk accesible por 443:

1. Terminación TLS TCP con Caddy 2.6+ (Caddy termina TLS y reenvía TCP bruto al relay de rustdesk). Caddy mejoró las características TCP en v2.6; con este enfoque obtienes certificados ACME automáticos y renovaciones.
2. Dejar que Caddy gestione solo certificados, y usar un proxy TCP (stunnel, HAProxy o Nginx stream) para consumir esos archivos de cert. Esto es una alternativa si tu versión de Caddy o tu entorno no soportan las funciones de proxy TCP necesarias.

A continuación hay una configuración mínima y pragmática de Caddy que usa Caddy para TLS en el puerto 443 y reenvía la conexión TCP sin procesar al relay de RustDesk en localhost:21115. Esto requiere Caddy v2.6+ (verifica con caddy version).

# Caddyfile (save as ./Caddyfile in the same folder as docker-compose.yml)
rustdesk.example.com:443 {
    # Caddy will obtain/renew certificates automatically
    reverse_proxy 127.0.0.1:21115 {
        # Use plain TCP transport; Caddy will accept TLS from clients and connect to the backend via TCP
        transport http {
            # We don't speak HTTP to the backend; keep minimal transport settings
        }
    }
}

Fragmento de docker-compose para ejecutar Caddy junto al servidor rustdesk (mismo proyecto):

cat >> docker-compose.yml <<'EOF'
  caddy:
    image: caddy:2.6.4
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
volumes:
  caddy_data:
  caddy_config:
EOF

docker compose up -d caddy

Caveat importante: el reverse_proxy incorporado en Caddy está orientado a HTTP, así que el comportamiento al proxear TCP bruto no HTTP depende de la versión de Caddy y las opciones de transporte. En la práctica muchos operadores usan las funciones de proxy TCP de Caddy introducidas en 2.6 para terminar TLS para backends TCP arbitrarios. Si encuentras problemas de protocolo, usa la opción (2) arriba: deja que Caddy maneje los certs y entrega los archivos de certificado a una pequeña capa TLS TCP (stunnel o HAProxy stream) que luego proxye TCP plano a rustdesk.

Ejemplo: Caddy como gestor de certs + stunnel para terminación TLS (vista rápida).

# 1) Ensure Caddy is running and has issued certs for rustdesk.example.com
# 2) Copy cert/key from Caddy storage into a place stunnel can read, or mount the same volume.
# 3) Run stunnel with a config that points TLS 443 -> 127.0.0.1:21115

# stunnel.conf snippet
[rustdesk]
accept = 443
connect = 127.0.0.1:21115
cert = /etc/stunnel/fullchain.pem
key = /etc/stunnel/privkey.pem

# In Docker world, mount Caddy's certificate files into the stunnel container path above.

Cualquiera de los dos enfoques te da un hostname (rustdesk.example.com) y el puerto 443 para los clientes. Prueba la conectividad desde otra máquina con: nc -vz rustdesk.example.com 443 — deberías establecer un handshake TLS si Caddy/stunnel están configurados correctamente.

Paso 3 — Apuntar los clientes a tu servidor autohospedado

Los clientes de RustDesk permiten servidores personalizados de ID/relay en la configuración. La UI exacta varía por plataforma y versión, pero los valores esenciales son:

• Servidor de ID / Rendezvous: rustdesk.example.com:443 (o tu dominio y puerto)
• Relay Server: rustdesk.example.com:443

En Windows: abre RustDesk > Settings > ID/Server y establece Id server y Relay server a rustdesk.example.com:443. En Linux y macOS las mismas opciones están en Preferences. Para instalaciones sin GUI, el cliente a veces acepta flags de línea de comandos o un archivo de configuración — consulta el repo del cliente para detalles.

Asegúrate de que los clientes sean recientes (1.2.x o más nuevos al momento de escribir). Los clientes más nuevos incluyen correcciones de protocolo y mejor traversal NAT. Si usas un cliente mucho más antiguo, el comportamiento puede variar.

Solución de problemas y refuerzo de seguridad

Problemas comunes y cómo depurarlos:

• Firewall: confirma que el firewall del VPS (ufw/iptables/proveedor en la nube) permite 80/443 entrantes. Para el contenedor rustdesk que escucha localmente en 21115, asegúrate de que exista el socket TCP (ss/netstat).
• Emisión de certificados: si Let's Encrypt no puede validar, Caddy registrará un error. Confirma que tu registro DNS A apunta al VPS y que el puerto 80 es accesible durante la emisión inicial.
• Incompatibilidad de protocolo: si ves éxito en el handshake TLS pero fallos de conexión desde el cliente, puede que estés proveyendo HTTP-only con Caddy por error. Usa el enfoque con stunnel en esos casos.
• Relay UDP: el rendimiento de RustDesk mejora con UDP para los frames de pantalla; si UDP es necesario y tu ruta de red bloquea UDP, caerás a relay TCP. Expón/reenvía los puertos UDP solo si controlas la red y sabes lo que haces.

Consejos para reforzar la seguridad:

• Ejecuta el servidor rustdesk bajo un usuario dedicado sin privilegios y mantiene las imágenes Docker actualizadas.
• Activa fail2ban o similar para limitar intentos repetidos fallidos, y monitorea logs (docker compose logs -f rustdesk-server).
• Haz copias de seguridad del directorio de datos del rustdesk server (en el ejemplo es ./data) con regularidad.
• Considera ejecutar el relay detrás de una red privada o VPC si operas múltiples relays.

Notas de escalado: un solo relay es suficiente para equipos pequeños. Para despliegues más grandes, ejecuta múltiples procesos hbbr en máquinas separadas y usa balanceo por DNS o un balanceador L4. Si necesitas funciones empresariales centralizadas como auditoría, ahí los proveedores comerciales pueden tener ventaja. Consulta nuestras piezas sobre self-hosted-remote-desktop y rustdesk-vs-anydesk para comparativas.

Mantenimiento, costos y recomendaciones finales

Los costos operativos son principalmente las tarifas del VPS y tu tiempo. Un VPS pequeño típico (1–2 CPU, 2–4 GB) se encuentra por $5–10/month (DigitalOcean, Vultr, Hetzner). Caddy y el servidor RustDesk son open-source; el costo recurrente principal es el hosting. Si necesitas facturación con GUI o soporte empresarial, los proveedores comerciales cobran por asiento o por sesión — consulta nuestras comparativas de precios como anydesk-pricing-explained y godeskflow-vs-teamviewer-pricing para más contexto.

Recomendaciones:

• Empieza con un solo VPS y el layout Docker Compose arriba. Prueba conexiones desde las redes exactas donde estarán tus usuarios (ISPs domésticos, firewalls corporativos).
• Si los clientes están frecuentemente detrás de firewalls muy restrictivos, pon tu relay en 443 y verifica que la terminación TLS funcione de forma fiable; usa Caddy+stunnel si el proxy TCP solo con Caddy causa problemas.
• Automatiza las copias de seguridad del directorio de datos del servidor y controla las actualizaciones de las imágenes. Las releases del servidor RustDesk avanzan; prueba las actualizaciones en staging si dependes de uptime en producción.

Si quieres una guía más corta sobre patrones de acceso remoto o alternativas, lee nuestros artículos relacionados: remote-access-setup-guide y remote-desktop-security.

¿Terminaste de leer? Si quieres probar un escritorio remoto totalmente open-source que se integra bien con el autohospedaje, descarga GoDesk o compara sus precios — ve GoDesk download y GoDesk pricing. Si estás listo para desplegar esta configuración de RustDesk, empieza creando el docker-compose.yml y el Caddyfile anteriores y ejecuta docker compose up -d. Para un arranque rápido, ve a /download para obtener los clientes y conectarte.