Escritorio remoto desde el navegador con WebRTC y un TURN propio
Controlar una PC a distancia desde cualquier navegador, sin instalar un cliente en el dispositivo desde el que se controla, es posible con WebRTC. Remote lo implementó de punta a punta: un agente en Windows que transmite la pantalla, un cliente web que la muestra y envía mouse y teclado, y un servidor propio que los pone en contacto. Funcionó en vivo, incluso a través de un firewall corporativo y por datos móviles. Estas son las piezas y lo que costó que funcionaran.
Las tres piezas
- El agente: una aplicación en la PC controlada que captura la pantalla, la envía como video y ejecuta las acciones de mouse y teclado que recibe. Se distribuye con un instalador que pide permisos de administrador.
- El cliente web: una página que muestra el video, captura el mouse, el teclado y el tacto, y los envía por un canal de datos. Funciona también en el celular y en pantalla completa.
- La señalización y el relé: un servidor que empareja agente y cliente, y un servidor TURN para cuando la conexión directa no es posible.
Señalización: un relé ciego
WebRTC necesita que las dos partes intercambien su oferta, su respuesta y sus candidatos de conexión antes de hablar directamente. Para eso basta un servidor WebSocket simple. El agente se conecta con su identificador y un token; el cliente se conecta indicando a qué agente quiere controlar. El servidor los empareja uno a uno: si un agente ya tiene un cliente activo, el segundo recibe un código de ocupado.
Una vez emparejados, el servidor solo reenvía mensajes entre ambos sin entender su contenido. No sabe nada de WebRTC. Esa simplicidad lo hace fácil de mantener y de razonar.
TURN: cuando la conexión directa no existe
En redes domésticas, la conexión directa entre dos equipos suele lograrse. Detrás de un firewall corporativo o de la red de un operador móvil, casi nunca. Ahí entra TURN, un servidor que retransmite el tráfico cuando no hay otra ruta. Montar uno propio permitió controlar su ubicación y su configuración.
Las credenciales de TURN no son fijas: el servidor de señalización las genera al emparejar, con una validez de una hora, firmando un nombre de usuario que incluye la fecha de expiración con un secreto compartido con el TURN. Así, una credencial filtrada deja de servir en poco tiempo.
Los bugs que enseñaron más
- Una URL de TURN que ya no respondía hacía fallar la conexión solo en ciertas redes, las que dependían del relé. En las demás todo parecía bien.
- El autoplay bloqueado en móviles: el video llegaba, pero el navegador no lo reproducía sin un gesto del usuario. La solución fue iniciar la reproducción desde un toque explícito.
- Un crash nativo del agente relacionado con la captura de audio, que tumbaba el proceso sin un error manejable.
- Cortes intermitentes causados por una VPN de terceros en uno de los equipos, que interfería con las rutas de red.
La limitación que no tiene arreglo simple
Desde una aplicación normal no se puede desbloquear Windows a distancia. La pantalla de inicio de sesión corre en un escritorio protegido y simular teclas ahí exige un controlador de dispositivo a nivel de kernel. Para un proyecto así, es una frontera clara: el equipo debe quedar con la sesión iniciada.
Estado del proyecto
El proyecto está pausado. No por un problema de arquitectura, sino por el costo de mantener la infraestructura y la estabilidad con la conectividad disponible en ese momento. Quedó documentado para reconstruirse desde cero: arquitectura, protocolo completo de mensajes y una retrospectiva con cada bug y su causa. Pausar un proyecto documentándolo así es lo que permite retomarlo sin empezar de nuevo.