RustDesk en cooperativas: soporte remoto con permiso

Un caso anonimizado muestra cómo ordenar soporte remoto con RustDesk Server OSS, tickets, claves, relay, permisos y respaldo.

ULTIMA MILLA · Proyectos · 11 de jun de 2026 · 4 min de lectura

Un acceso remoto quedó habilitado tres semanas después de cerrar el ticket. La cooperativa eléctrica tenía enlaces rurales, una guardia chica y varias PCs de administración que recibían soporte por urgencia. RustDesk Server OSS permitió llevar el ID server y el relay a infraestructura propia, con permiso escrito y registro operativo. Este caso anonimizado explica qué se instala, dónde queda la evidencia y cómo probar que el acceso se corta.

Dónde aparece el soporte sin registro

La cifra que aterriza la decisión está en la guía de instalación de RustDesk Server OSS: cuando falla la conexión directa, el tráfico de relay puede ir de 30 K/s a 3 M/s para una pantalla 1920x1080; para trabajo de oficina, el documento estima alrededor de 100 K/s. En una cooperativa con enlaces rurales, ese dato define si el soporte remoto compite con facturación o atención al vecino. El dato global llega desde la Stack Overflow Developer Survey 2025, que reunió 49.009 respuestas de 177 países y marca al trabajo remoto como una práctica extendida en equipos técnicos. La lectura local es más concreta: soporte ya no siempre viaja al sitio, y cada conexión debe tener dueño, horario y cierre. El antagonista era el acceso remoto sin ticket. Una contraseña guardada por apuro resolvía una impresora, pero también abría la posibilidad de entrar fuera de horario sin que nadie pudiera explicar por qué. En la sala técnica, una etiqueta con el nombre del transformador seguía atada a un patch cord rojo. Esa prolijidad física faltaba en el acceso remoto.

Cómo funciona por dentro

El flujo quedó en seis pasos. Primero, el equipo de soporte registra el pedido en GLPI u otra mesa de ayuda con solicitante, equipo y motivo. Segundo, el cliente RustDesk apunta al ID Server y a la clave pública del servidor propio. Tercero, hbbs coordina identidad y encuentro entre cliente y operador. Cuarto, hbbr entrega relay cuando no hay conexión directa. Quinto, el operador abre sesión dentro de la ventana aprobada y deja evidencia en el ticket. Sexto, backup y revisión de configuración prueban que el servidor vuelve y que los accesos vencidos quedan cerrados. La página de RustDesk Server OSS separa el servidor de señalización y el relay. La guía de Docker muestra un despliegue reproducible con servicios y volúmenes. RustDesk recibe solicitudes de conexión y entrega coordinación o relay; el inventario de permisos puede vivir en PostgreSQL dentro de la mesa de ayuda, dónde se guardan equipo, usuario, autorización, horario y cierre. Los permisos se separan por rol. Mesa de ayuda abre el ticket. Sistemas administra servidor, clave pública y firewall. Un proveedor externo recibe ventana, equipo y responsable. Administración consulta evidencia. Nadie conserva acceso permanente sin fecha de revisión. El backup copia configuración, claves del servidor, compose, tickets e inventario, y una restauración levanta hbbs y hbbr en otro host de prueba.

Qué se instala o configura primero

El primer entregable verificable es una sesión remota de prueba con ticket, autorización, cliente apuntando al servidor propio, conexión, cierre y bloqueo posterior. La pila mínima usa RustDesk Server OSS, Docker, TLS cuando corresponde, firewall documentado, GLPI para tickets, PostgreSQL para inventario y respaldo diario de configuración. El costo de servidor puede quedar entre USD 20 y USD 60 mensuales, unos ARS 29.100 a ARS 87.300 al dólar vendedor de $1.455, sin contar horas de soporte ni enlaces de respaldo. UMSA puede intervenir después de mapear sucursales, equipos críticos y proveedores. La primera semana debe dejar un listado de equipos con responsable, un servidor propio, una regla de firewall y una prueba dónde el proveedor pierde acceso al vencer el ticket. La configuración inicial debe evitar que el acceso remoto sea una vía paralela a la mesa de ayuda. Cada conexión se ata a un equipo, una persona y un motivo. El tablero muestra sesiones abiertas, equipos sin responsable, tickets vencidos y servidores que no reportan. El enlace rural se mide durante una sesión real para ajustar calidad antes de que la guardia lo necesite.

Dónde se rompe y cómo probarlo

El primer riesgo es que un cliente apunte al servidor público por error. La señal aparece cuando el equipo conecta aunque el servidor propio esté apagado. La prueba corta hbbs, abre el cliente y confirma que no inicia sesión. El segundo riesgo es saturar el enlace con relay. La señal aparece cuando facturación sube latencia mientras soporte toma control. La prueba mide consumo de una sesión de quince minutos, compara tráfico y ajusta resolución o ventana horaria. El tercer riesgo es dejar claves copiadas en chats. La señal aparece cuando un proveedor puede entrar sin ticket activo. La prueba rota credenciales, cambia clave pública si corresponde y exige nueva autorización. El cuarto riesgo es restaurar solo el binario. La señal aparece cuando el servidor vuelve, pero los clientes pierden configuración o los tickets no unen equipo y usuario. La prueba restaura en otro host, conecta una PC de laboratorio y verifica ticket, responsable y cierre. El soporte remoto queda ordenado cuando la cooperativa puede decir quién entró, por qué entró y cuándo perdió permiso.