grdpwasm - Client RDP basé sur le web
(github.com/nakagami)- Un client RDP basé sur le web permettant de se connecter à un Bureau à distance Windows depuis un simple navigateur, sans plugin
- Sépare le Go WebAssembly côté navigateur et un proxy WebSocket-vers-TCP côté serveur, qui prend en charge à la place du navigateur les connexions TCP RDP qu’il ne peut pas ouvrir directement
- La connexion suit le flux
Browser -> WebSocket -> proxy -> TCP -> RDP Server; une fois connecté, l’écran distant s’affiche dans un canvas et les entrées clavier/souris sont transmises - Les périphériques d’entrée prennent en charge un clavier basé sur les RDP scan codes ainsi qu’une souris avec déplacement, clic et molette ; l’audio distant est reçu via RDPSND puis lu avec la Web Audio API
- Comme l’architecture du proxy autorise toutes les origins, il faut l’exécuter uniquement sur un réseau de confiance ou ajouter HTTPS/WSS et une couche d’authentification avant toute exposition externe
Vue d’ensemble du projet
- Fonctionne comme un client RDP basé sur le web permettant d’accéder à un Bureau à distance Windows depuis le navigateur, sans plugin
- L’implémentation repose sur la combinaison de Go WebAssembly et de grdp, avec une architecture séparant la partie exécutée dans le navigateur et le composant proxy intermédiaire
- Comme le navigateur ne peut pas ouvrir directement de socket TCP brute, un proxy Go léger est nécessaire pour relier la connexion WebSocket au port TCP du serveur RDP
Architecture et mode de fonctionnement
- Le chemin complet suit l’ordre
Browser (WASM) -> WebSocket -> proxy (Go) -> TCP -> RDP Server - Dans le navigateur, c’est le binaire WASM qui s’exécute, tandis que le proxy joue à la fois le rôle de pont WebSocket-vers-TCP et de serveur de fichiers statiques
- Le résultat de
make allest réparti entrestatic/main.wasm, exécuté dans le navigateur,static/wasm_exec.js, fichier d’assistance au runtime Go, etproxy/proxy, le serveur proxy - Grâce à cette structure, la partie navigateur gère la connexion avec des technologies web standard, tandis que le proxy prend en charge la communication TCP réelle avec le serveur RDP
Flux d’utilisation et interface utilisateur
- Ouvrez
http://localhost:8080dans le navigateur, saisissez les valeurs Host, Port, Domain, User, Password, Width, Height dans le formulaire de connexion, puis cliquez sur Connect pour démarrer la session - La valeur par défaut de Port est
3389, et Domain peut être laissé vide en cas d’utilisation d’un compte local - Une fois la connexion établie, le Bureau à distance s’affiche dans le canvas ; pour recevoir les entrées clavier, il faut cliquer sur le canvas
- Cliquez sur Disconnect pour terminer la session
Périphériques d’entrée et prise en charge audio
- Toutes les entrées clavier standard sont transmises au Bureau à distance via les RDP scan codes
- La souris prend en charge le déplacement, les clics de bouton et la molette de défilement
- L’onglet du navigateur doit avoir le focus pour que les événements clavier soient transmis ; si la saisie s’interrompt, il faut recliquer dans la zone du canvas
- L’audio distant est diffusé via RDPSND et lu dans le navigateur avec la Web Audio API
- Le format audio est indiqué comme PCM 44100 Hz, stereo, 16-bit signed little-endian
Conditions d’exploitation et points de vigilance en matière de sécurité
- Les prérequis sont Go 1.24 ou supérieur et un serveur RDP accessible ; le serveur cible peut être Windows ou tout hôte compatible RDP
- Le proxy autorise les connexions depuis toutes les origins ; il doit donc être exécuté uniquement sur un réseau de confiance ou complété par une couche d’authentification avant exposition à Internet
- Les identifiants étant transmis du navigateur au proxy via WebSocket, l’utilisation de HTTPS/WSS est nécessaire sur les réseaux non fiables
- Le README mentionne aussi la possibilité d’utiliser un reverse proxy avec terminaison TLS comme nginx ou Caddy
Exécution et informations complémentaires
- L’exécution est possible via
make serveou./proxy/proxy -listen :8080 -static static - Les options du proxy permettent de définir l’adresse et le port d’écoute avec
-listen, ainsi que le répertoire de fichiers statiques avec-static - Les cibles de développement sont réparties entre
make wasmpour reconstruire uniquement le WASM,make proxypour reconstruire uniquement le proxy,make wasm_execpour mettre à jourwasm_exec.js, etmake cleanpour supprimer les artefacts - La licence est GPLv3, avec une référence supplémentaire à la licence de grdp
2 commentaires
Mais honnêtement, je ne vois pas le véritable avantage.
Au final, ce n’est qu’un client, donc il ne peut pas non plus imposer des exigences côté serveur.
Et ce n’est même pas accessible uniquement avec un navigateur pur.
Commentaires sur Hacker News
Ça a l’air plutôt sympa. Avec la prise en charge de l’enregistrement de session et de l’authentification SSO, ça pourrait être utilisé directement comme hôte de rebond RDP.
J’ai déjà utilisé quelque chose de similaire avec Azure Bastion : on se connecte au portail Azure avec la méthode d’authentification configurée pour le tenant, puis on ouvre une session RDP vers la VM dans le navigateur, avant de se connecter avec un compte local côté VM. La gestion des fichiers et du presse-papiers fonctionne plutôt bien, et les sessions console sont aussi prises en charge dans le navigateur.
Je ne sais pas si c’est possible côté Windows/RDP car je ne l’ai pas testé, mais le SSH dans le navigateur de GCP était de loin l’une des meilleures implémentations que j’aie vues jusqu’à présent.
Même sur Linux, j’ai parfois trouvé que xrdp était meilleur que d’autres alternatives.
L’une des grandes valeurs que cela apporte, c’est la séparation de l’interface d’administration des VM/serveurs. Rien que le fait que le service d’administration d’un serveur web ne soit pas exposé sur la même IP, le même domaine ou la même interface que le service HTTP améliore considérablement la sécurité.
Le presse-papiers dans un RDP de navigateur est un cauchemar discret. La négociation du protocole réseau elle-même fonctionne bien, mais l’API Clipboard côté navigateur est contrainte par les permissions et les exigences de geste utilisateur.
Pour la lecture, la plupart des navigateurs demandent pratiquement une confirmation à l’utilisateur à chaque fois. Du coup, il faut soit créer un tampon de presse-papiers séparé dans la page, soit accepter que le collage vers l’intérieur du RDP soit fluide mais que la copie depuis le RDP vers l’extérieur exige un clic à chaque fois.
Aucune de ces solutions ne correspond vraiment au comportement que les gens attendent d’un client RDP web. Avant de considérer cela comme équivalent au mstsc natif, il faut absolument vérifier comment le comportement diffère entre Chrome et Firefox.
Depuis que HP a abandonné Anyware / Teradici / PCoIP, beaucoup de gens cherchent une alternative. Il y a notamment un vrai besoin pour les configurations avec multi-écrans haute résolution, 60fps, lecture à grande profondeur de bits, prise en charge des tablettes Wacom et compatibilité avec les trois OS.
Côté solutions payantes, il y a Parsec et DCV, et c’est encourageant de voir des initiatives open source. Avec des projets comme rustdesk, kyber et teraguchi, la communauté a clairement besoin d’options open source performantes.
https://github.com/rustdesk/rustdesk
https://github.com/thedepartmentofexternalservices/teraguchi
https://kyber.tech/
Ça a l’air intéressant, mais je suis surpris que la fonction la plus importante ne soit pas mentionnée. Je me demande à quel point le partage du presse-papiers fonctionne bien en pratique.
Le partage du presse-papiers ainsi que l’upload/download via des lecteurs partagés sont des fonctionnalités de FreeRDP, donc relativement faciles à exploiter telles quelles.
Et l’enregistrement de session est non négociable dans un environnement PAM.
[1] https://adaptive.live
La mise à l’échelle du bureau, la prise en charge du multi-écran, le transfert de fichiers, la redirection de lecteurs et la redirection de périphériques sont tous importants.
Je me demande aussi si cela fonctionne pour ouvrir les fichiers RDP reçus depuis CyberArk PAM.
Je me demande également si le client RDP peut intercepter Alt-Tab à l’intérieur d’un onglet du navigateur.
C’était autrefois le principal problème du RDP navigateur de Guacamole.
C’est intéressant techniquement, mais comme il existe déjà des clients RDP natifs sur presque toutes les plateformes, je ne vois pas très bien pourquoi ce serait nécessaire.
https://guacamole.apache.org/