Marcio Cunha

Cómo usar RustDesk para soporte remoto seguro y auditable

Aprenda a configurar servidores de relay propios en RustDesk, garantizando cifrado de extremo a extremo y cumplimiento total con normativas corporativas.

Marcio Cunha•7 min
También disponible en:PortuguêsEnglish
Resumen
  • Los servidores de relay propios eliminan la dependencia de infraestructuras públicas de terceros durante el soporte remoto.
  • El cifrado de extremo a extremo protege el tráfico de pantalla y comandos frente a intentos de interceptación en la red.
  • El aislamiento del tráfico corporativo requiere el uso de VLANs dedicadas según buenas prácticas de seguridad.
  • Las políticas corporativas de acceso exigen auditorías rigurosas y registro de todas las sesiones remotas activas.
  • La autohospedaje de herramientas reduce significativamente los riesgos legales y las fugas de datos confidenciales.

Por qué evitar los servidores públicos en el soporte remoto?

Cuando pensamos en acceso remoto a escritorios, las herramientas tradicionales facilitan la tarea conectando dos puntos a través de internet sin complicaciones. En la práctica, esto significa que el tráfico pasa por ordenadores intermediarios repartidos por todo el mundo para encontrar el camino entre el técnico y el cliente. Para quienes trabajan en entornos corporativos estrictos, esta comodidad introduce un grave problema de seguridad y privacidad. Al fin y al cabo, datos sensibles de su empresa y pantallas de clientes viajan por servidores que usted no controla y cuya infraestructura interna carece de transparencia. Garantizar el cumplimiento de las normativas de protección de datos exige mantener el control de los servidores de conexión estrictamente dentro de su propia infraestructura de TI.

Para resolver este dilema sin perder agilidad, podemos montar nuestra propia central de tráfico utilizando el software libre RustDesk. Los ecosistemas de redes modernos suelen presentar cuellos de botella cuando están mal configurados, por lo que es vital entender cómo optimizar la infraestructura para eliminar pérdida de paquetes y jitter durante sesiones pesadas de vídeo. Alojar su propio servidor de relay garantiza que ningún dato circule por ordenadores ajenos, asegurando soberanía absoluta sobre el canal de soporte. Además, antes de exponer cualquier servicio a internet, resulta crucial diseñar una red segura con VLANs para aislar el tráfico corporativo y evitar movimientos laterales no deseados ante brechas en la red física.

Comprendiendo la arquitectura de RustDesk Server (hbbs y hbbr)

RustDesk divide su backend del lado del servidor en dos componentes principales integrados: hbbs y hbbr. El servicio hbbs actúa como el director de orquesta, gestionando el registro de equipos y el intercambio inicial de claves criptográficas. Por otro lado, el hbbr funciona como el cartero pesado, siendo el servidor de relay propiamente dicho que transmite flujos de vídeo y comandos de ratón cuando una conexión directa a internet se ve bloqueada por routers restrictivos y cortafuegos. En la práctica, hbbs indica quién puede hablar con quién, mientras hbbr asume el peso de la conversación si la vía directa falla.

Configurar ambos servicios requiere atención a los puertos de red para que el tráfico fluya sin bloqueos operativos. En la mayoría de despliegues, utilizamos puertos específicos como el 21115 para registro, el 21116 para escucha TCP y UDP, y el 21117 para el servicio de relay de datos. De forma similar a lo que ocurre cuando creamos un túnel seguro corporativo usando el RustDesk, la clara separación entre señalización y transmisión de datos asegura que el cifrado se negocie de forma aislada y segura antes de enviar cualquier paquete de imagen. Esta división arquitectónica impide que atacantes manipulen sesiones, ya que cada intercambio de claves pasa por validaciones estrictas en el servidor de control centralizado.

Paso a paso para desplegar su propio servidor de relay

El despliegue de una infraestructura propia de relay se realiza de forma limpia mediante contenedores Docker en un servidor Linux dedicado dentro de su empresa o nube privada. El primer paso consiste en preparar el archivo de configuración Docker Compose con los servicios necesarios y los puertos mapeados correctamente. Asegúrese de que el cortafuegos de su servidor permita conexiones entrantes en estos puertos específicos antes de iniciar los servicios. Organizar el entorno con antelación evita fallos de comunicación difíciles de depurar más adelante.

Cree un directorio en su servidor para almacenar los archivos de configuración y los datos persistentes de la aplicación. A continuación, cree el archivo docker-compose.yml utilizando su editor de texto preferido en la terminal del sistema operativo. Inserte el contenido estructurado a continuación para poner en marcha tanto el servidor de señalización como el relay simultáneamente con un aislamiento adecuado de volúmenes.

version: '3'
services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs -r tu-ip-o-dominio:21117
    volumes:
      - ./data:/root
    networks:
      - rustdesk-net
    ports:
      - 21115:21115
      - 21116:21116
      - 21116:21116/udp
    restart: unless-stopped

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr -r tu-ip-o-dominio:21117
    volumes:
      - ./data:/root
    networks:
      - rustdesk-net
    ports:
      - 21117:21117
    restart: unless-stopped

networks:
  rustdesk-net:
    driver: bridge

Con el archivo preparado en el servidor, ejecute el comando de inicio en segundo plano para poner los servicios en operación continua. El sistema descargará las imágenes necesarias e iniciará los contenedores automáticamente, creando la carpeta de datos donde se generará la clave pública de cifrado. Compruebe que los procesos se ejecutan correctamente revisando los registros generados por el gestor de contenedores.

  1. Abra la terminal en el directorio donde guardó el archivo de configuración de Docker Compose en el servidor.
  2. Ejecute el comando para desplegar los servicios en segundo plano de forma segura.
    docker compose up -d
  3. Compruebe que los contenedores están activos y escuchando en los puertos correctos sin errores en los registros.
    docker compose logs -f

Cifrado de extremo a extremo y seguridad en la transmisión

La seguridad en herramientas de acceso remoto no depende únicamente de un canal cifrado, sino de cómo se distribuyen y validan las claves criptográficas entre las partes. RustDesk utiliza cifrado moderno basado en curvas elípticas por defecto en todas las sesiones establecidas. En la práctica, esto significa que aunque alguien logre interceptar el tráfico que pasa por su servidor de relay, los datos seguirán siendo ilegibles sin la clave privada que reside exclusivamente en los dispositivos autorizados. El servidor de relay actúa meramente como un conducto ciego que reenvía paquetes cifrados sin poder abrirlos.

Para reforzar aún más el cumplimiento corporativo, podemos inyectar la clave pública generada automáticamente por el servidor hbbs directamente en los instaladores o configuraciones de los clientes. Esta clave actúa como un certificado de confianza absoluto: la aplicación del usuario solo aceptará comunicarse con servidores que presenten la firma criptográfica correspondiente. De este modo, se previenen eficazmente ataques de intermediarios maliciosos donde un servidor falso intente suplantar la central corporativa para robar credenciales de acceso o inspeccionar sesiones de soporte técnico en equipos de la compañía.

Cumplimiento corporativo y auditoría de accesos remotos

Las grandes empresas y entidades reguladas deben responder a auditorías rigurosas sobre quién accedió a qué servidores y en qué marcas de tiempo exactas. Utilizar soluciones comerciales de soporte remoto suele dejarnos dependientes de informes propietarios almacenados en nubes de terceros. Al mantener el control total de la infraestructura de RustDesk, su equipo de seguridad de la información adquiere la capacidad de cruzar registros de conexión directamente con los logs de cortafuegos y sistemas de gestión de eventos de seguridad. Esto satisface prontamente los requisitos de normativas como GDPR e ISO 27001 respecto al control estricto de privilegios de acceso.

Más allá de los registros nativos de los contenedores, es muy recomendable centralizar dichos registros en un sistema de gestión de eventos para análisis en tiempo real y detección de anomalías. Si un técnico necesita acceder a una máquina crítica fuera del horario laboral, el sistema registra la IP de origen, la duración de la sesión y la clave empleada. Esta transparencia operativa transforma una utilidad de conveniencia en un activo de seguridad auditable, ofreciendo tranquilidad tanto a los gestores de TI como a los departamentos de auditoría interna y cumplimiento normativo.

Consideraciones finales

Implementar una solución de soporte remoto autosuficiente con relay propio y cifrado robusto deja de ser un lujo técnico para convertirse en una necesidad estratégica en la era de la seguridad de la información descentralizada. Hemos visto que gestionar la propia infraestructura elimina los riesgos inherentes al uso de servidores públicos desconocidos, garantizando total privacidad para los datos corporativos en tránsito. Combinar tecnologías ligeras como Docker con arquitecturas cifradas de extremo a extremo demuestra que es posible mantener la agilidad operativa sin sacrificar el rigor de los estándares de cumplimiento corporativo.

Mantener un control estricto sobre las claves de acceso y auditar constantemente los registros de conexión fortalece la postura de seguridad de la organización frente a amenazas externas y fugas internas. Al adoptar estas prácticas, su equipo de ingeniería y soporte garantiza un entorno de trabajo resiliente, preparado para satisfacer las exigencias normativas más estrictas del mercado actual.