Montar una infraestructura propia de acceso remoto con RustDesk Self-Hosted permite sustituir o complementar servicios comerciales como AnyDesk o TeamViewer manteniendo bajo control los servidores que intervienen en las conexiones. Una arquitectura relativamente sencilla puede combinar Ubuntu Server, Docker, RustDesk Server, FortiGate, FortiManager y DDNS para proporcionar acceso desde Internet sin obligar al técnico a establecer previamente una VPN.
Las claves de RustDesk Self-Hosted en 20 segundos
- RustDesk permite desplegar servidores propios de identificación y relay mediante HBBS y HBBR.
- Ambos servicios pueden ejecutarse como contenedores Docker sobre un servidor Linux.
- FortiGate publica únicamente los puertos necesarios mediante VIP, DNAT y políticas específicas.
- Un FQDN con DDNS evita depender directamente de una dirección IP pública cambiante.
- Los clientes deben configurarse para utilizar el servidor privado y su clave pública.
La ventaja del planteamiento self-hosted no consiste simplemente en instalar otro programa de escritorio remoto. La diferencia está en controlar la infraestructura utilizada para localizar los equipos y, cuando una comunicación directa no resulta posible, retransmitir el tráfico.
La arquitectura de ejemplo parte de un Ubuntu Server con la dirección privada 10.20.30.20, protegido por un FortiGate. Sobre Linux se ejecutan los componentes de RustDesk Server mediante Docker. Desde Internet, los clientes utilizan un nombre como rustdesk.empresa.com, mientras FortiGate realiza la traducción hacia el servidor interno.
Cómo funciona RustDesk Self-Hosted
Antes de desplegarlo conviene distinguir los dos componentes principales de RustDesk Server.
HBBS es el servidor de identificación y señalización. Ayuda a que los clientes registrados localicen al otro extremo y puedan negociar la conexión.
HBBR funciona como servidor de relay. Entra en juego cuando los dos extremos no pueden establecer adecuadamente una comunicación directa y necesitan que el tráfico pase por una infraestructura intermedia.
En una instalación privada ambos servicios quedan bajo control de la organización.
Una arquitectura básica sería:
Cliente remoto | Internet |rustdesk.empresa.com | FortiGate VIP / DNAT / Firewall |Ubuntu Server10.20.30.20 | Docker / \ HBBS HBBR
Los equipos de la organización se configuran para utilizar este servidor en lugar de depender de los servidores públicos de RustDesk.
Paso 1: preparar Ubuntu Server y Docker
El primer elemento necesario es un servidor Linux. Puede utilizarse Ubuntu Server en una máquina física o virtual, siempre que tenga conectividad adecuada con Internet y con las redes donde se encuentren los equipos que deban administrarse.
Conviene comenzar actualizando el sistema:
sudo apt updatesudo apt upgrade -y
Después puede instalarse Docker siguiendo el procedimiento soportado para la versión de Ubuntu utilizada.
Una vez disponible, se comprueba su funcionamiento:
docker --versiondocker ps
También resulta recomendable reservar una dirección IP interna fija para el servidor. En el ejemplo se utiliza:
10.20.30.20
Esto evita que un cambio de dirección mediante DHCP deje apuntando las reglas NAT del firewall hacia otro equipo.
Paso 2: desplegar HBBS y HBBR con Docker
RustDesk proporciona su servidor para despliegues propios y permite ejecutar por separado HBBS y HBBR.
Una forma cómoda de mantener la configuración es utilizar Docker Compose y un directorio persistente para los datos.
Por ejemplo:
services: hbbs: image: rustdesk/rustdesk-server:latest command: hbbs volumes: - ./data:/root network_mode: "host" depends_on: - hbbr restart: unless-stopped hbbr: image: rustdesk/rustdesk-server:latest command: hbbr volumes: - ./data:/root network_mode: "host" restart: unless-stopped
Después:
docker compose up -d
Y se comprueba que los dos contenedores permanecen activos:
docker ps
Para revisar los registros:
docker logs -f hbbs
o:
docker logs -f hbbr
En producción es preferible fijar una versión concreta de la imagen en lugar de mantener permanentemente latest. Así una actualización no modifica inesperadamente un servidor que presta acceso remoto a sistemas internos.
También deben mantenerse actualizados Ubuntu, Docker y RustDesk Server dentro de un procedimiento controlado de mantenimiento.
Paso 3: conocer los puertos antes de tocar FortiGate
Este punto merece especial atención porque copiar reglas NAT de una captura o tutorial antiguo puede terminar exponiendo puertos innecesarios o dejando alguna función sin servicio.
RustDesk Server utiliza varios puertos alrededor del rango 21114-21119, dependiendo de los componentes y funciones habilitados. HBBS utiliza principalmente los servicios de identificación y señalización, mientras HBBR necesita su puerto de relay.
Por tanto, antes de crear las reglas conviene consultar la documentación de la versión de RustDesk Server instalada y comprobar qué servicios están realmente escuchando:
ss -tulpn
También puede comprobarse desde Docker:
docker ps
La regla recomendable para un firewall perimetral es sencilla: publicar solamente aquello que la instalación necesita realmente.
Paso 4: publicar RustDesk mediante FortiGate
Con el servidor funcionando internamente llega la parte más delicada: hacerlo accesible desde Internet.
En FortiGate puede crearse una Virtual IP (VIP) que traduzca la IP pública y los puertos correspondientes hacia:
10.20.30.20
Conceptualmente:
Internet |IP pública |FortiGate |VIP + DNAT |10.20.30.20 |HBBS / HBBR
Después se crean los objetos de servicio TCP y UDP estrictamente necesarios y una política desde la interfaz WAN hacia la red donde reside RustDesk.
No conviene crear una regla genérica ANY -> 10.20.30.20.
Una política limitada a los servicios necesarios reduce la superficie expuesta y facilita posteriormente la revisión de logs y resolución de incidencias.
Si la infraestructura utiliza FortiManager, estos objetos, políticas y cambios pueden administrarse desde allí para mantener centralizada la configuración y su despliegue sobre los FortiGate gestionados.
Paso 5: utilizar un FQDN y DDNS
Una dirección como:
rustdesk.empresa.com
es preferible a configurar manualmente una IP en todos los clientes.
Si la conexión no dispone de IP pública estática, puede utilizarse un mecanismo de DNS dinámico (DDNS) para actualizar el registro cuando cambie la dirección asignada por el operador.
En el escenario planteado se utiliza FortiDDNS.
El flujo pasa entonces a ser:
RustDesk Client |rustdesk.empresa.com | DNS/DDNS |IP pública actual | FortiGate |10.20.30.20
Si posteriormente cambia la dirección pública, los clientes pueden continuar utilizando el mismo nombre.
Paso 6: configurar los clientes RustDesk
Tener los servidores funcionando no sirve de mucho si los clientes continúan utilizando la infraestructura pública predeterminada.
Cada cliente debe configurarse para apuntar al servidor privado:
ID Server:rustdesk.empresa.comRelay Server:rustdesk.empresa.com
Además, debe utilizarse la clave pública correspondiente al servidor.
La gestión de esta clave es especialmente importante. No debería tratarse como un parámetro secundario de instalación: los clientes necesitan validar que están hablando con la infraestructura RustDesk prevista por la organización.
En despliegues con numerosos dispositivos interesa automatizar la configuración para evitar que cada usuario tenga que introducir manualmente servidores y claves.
Paso 7: comprobar que realmente funciona desde Internet
Una prueba realizada únicamente desde la LAN demuestra poco. La validación debe hacerse desde una red externa.
Por ejemplo, pueden comprobarse los puertos TCP publicados mediante nc:
nc-zv rustdesk.empresa.com 21115
Para UDP puede utilizarse:
nc-zvu rustdesk.empresa.com 21116
Las pruebas deben adaptarse, de nuevo, a los puertos utilizados por la versión y configuración desplegadas.
Mientras se establece una sesión conviene observar los logs:
docker logs -f hbbs
docker logs -f hbbr
Y, cuando algo no cuadre, tcpdump sigue siendo una de las herramientas más útiles:
sudo tcpdump -ni any host IP_DEL_CLIENTE
También puede filtrarse por puerto:
sudo tcpdump -ni any port 21117
Esto ayuda a responder una pregunta básica durante el diagnóstico: ¿el paquete está llegando realmente al servidor?
Si llega al FortiGate pero no al Ubuntu, el problema probablemente estará en NAT, routing o políticas. Si llega a Ubuntu pero el servicio no responde, habrá que revisar Docker, puertos y configuración de RustDesk.
Paso 8: validar una sesión completa
La prueba final debería reproducir el uso real:
Equipo técnico externo ↓ Internet ↓ DNS ↓ FortiGate VIP / DNAT ↓ RustDesk Server HBBS / HBBR ↓ Equipo gestionado
El técnico debería poder localizar el dispositivo y establecer la sesión utilizando la infraestructura privada configurada.
Que funcione sin VPN es técnicamente posible, pero no significa que deba considerarse equivalente a una VPN ni que sea apropiado en todas las organizaciones. Se está publicando deliberadamente un servicio de acceso remoto en Internet y, por tanto, debe incorporarse a las políticas de seguridad, actualización, monitorización y control de accesos de la empresa.
Seguridad: self-hosted no significa seguro automáticamente
Alojar RustDesk internamente proporciona control sobre la infraestructura, pero ese control trae consigo responsabilidades.
El servidor debería estar segmentado del resto de sistemas internos, mantenerse actualizado y disponer únicamente de los puertos imprescindibles. También conviene registrar los accesos, revisar periódicamente las políticas del firewall y limitar los privilegios de administración.
En entornos empresariales deberían estudiarse además mecanismos adicionales de autenticación, control de usuarios y dispositivos, restricciones de acceso y las capacidades disponibles en la edición de RustDesk elegida.
La organización también necesita definir quién puede prestar soporte, a qué equipos puede acceder y cómo se autorizan las sesiones. La seguridad no termina en la conexión cifrada.
Y existe una diferencia importante respecto a utilizar un SaaS: al desplegar la infraestructura propia, la disponibilidad también pasa a ser responsabilidad de la empresa. Si falla el servidor, el acceso remoto puede quedar afectado precisamente cuando más se necesita.
Por eso un despliegue empresarial puede requerir monitorización, copias de seguridad de la configuración, procedimientos de recuperación y, dependiendo de su criticidad, redundancia.
Por qué puede interesar frente a AnyDesk o TeamViewer
RustDesk Self-Hosted resulta especialmente atractivo para organizaciones que quieren tener mayor control sobre la infraestructura utilizada para sus sesiones remotas.
El planteamiento permite decidir dónde se ejecutan HBBS y HBBR, qué red los aloja, qué puertos se publican y cómo se integran con el firewall corporativo.
También facilita desplegar la infraestructura en un centro de datos propio, un servidor dedicado, una nube privada o una máquina virtual bajo control de la organización.
Eso no convierte automáticamente a RustDesk en sustituto directo de cualquier plataforma comercial. Antes de una migración deben compararse características como administración centralizada, identidad, auditoría, soporte, alta disponibilidad, políticas de acceso, cumplimiento normativo y gestión de dispositivos.
Para un administrador de sistemas, sin embargo, el proyecto tiene un interés añadido. Obliga a trabajar de extremo a extremo con Linux, Docker, DNS, NAT, TCP/UDP, firewalls, routing, logs y captura de paquetes. Cuando finalmente aparece el escritorio del equipo remoto, detrás hay bastante más infraestructura de la que deja ver la interfaz de RustDesk.
Preguntas frecuentes
¿Se puede utilizar RustDesk Self-Hosted sin VPN?
Sí. Es posible publicar los servicios necesarios mediante un firewall y permitir que los clientes se conecten desde Internet al servidor privado. Esto requiere proteger y mantener correctamente el servicio expuesto.
¿Para qué sirven HBBS y HBBR?
HBBS proporciona funciones de identificación y señalización entre clientes. HBBR actúa como relay cuando los extremos necesitan retransmitir la comunicación a través del servidor.
¿Se puede ejecutar RustDesk Server con Docker?
Sí. RustDesk Server puede desplegarse mediante contenedores, lo que permite ejecutar HBBS y HBBR sobre un servidor Linux y mantener persistentes sus datos y claves.
¿RustDesk Self-Hosted puede sustituir a AnyDesk?
Puede cubrir numerosos escenarios de acceso y soporte remoto, pero una migración empresarial debe comparar previamente funciones de seguridad, administración, auditoría, soporte y disponibilidad necesarias en cada organización.
