RustDesk, l’alternative open source à TeamViewer que l’on peut auto-héberger

I. Présentation

Dans ce tutoriel, nous allons découvrir RustDesk, une solution de prise en main à distance gratuite et open source (licence GPL-3.0), dans le même esprit que TeamViewer, AnyDesk et consort. RustDesk est utilisable en s'appuyant sur les serveurs publics, mais il est également possible d'auto-héberger sa propre instance en montant un serveur RustDesk : particulièrement intéressant, d'autant plus qu'il n'y a pas besoin de payer de licence.

Le serveur RustDesk est installable sur une machine Linux, une machine Windows ou via Docker. Sa compatibilité avec Docker va nous permettre de le mettre en place sur un NAS Synology de façon relativement simple. Dans cet article, nous allons voir comment héberger RustDesk Server sur un NAS Synology mais aussi comment le faire tourner sur un serveur Debian 11 avec Docker.

D'après le GitHub de RustDesk, il y a trois serveurs gratuits pour gérer les connexions et ils sont situés à Séoul, Singapour et Dallas. Cette liste va probablement évoluer avec le temps, mais cela doit vous inciter à utiliser votre propre serveur, car il n'y a pas encore de relais public en Europe ou en France.

Voici quelques liens utiles :

Il y a également un Discord et un Reddit pour les échanges et l'aspect communautaire.

A. Les fonctionnalités de RustDesk

Principalement codé en Rust, d'où son nom, RustDesk va se permettre de se connecter à distance sur un appareil, par exemple à partir d'un ordinateur A vers un ordinateur B, afin de prendre la main et effectuer une tâche d'administration ou intervenir dans le cadre d'une opération de support informatique. Cet outil est disponible sur les différentes plateformes : Windows, macOS, Linux (deb / rpm), Android et iOS, ce qui va permettre de l'utiliser aussi bien sur un poste de travail que sur une tablette ou un smartphone. Il y a une autre alternative qui consiste à utiliser son navigateur pour se connecter sur un hôte distant via le site http://web.rustdesk.com. Cette fonctionnalité est actuellement en Beta et fonctionne en HTTP, donc il vaut mieux attendre.

Cette solution présente l'avantage de pouvoir être auto-hébergée, ce qui est important d'un point de vue du respect de la vie privée. Ensuite, les connexions entre l'hôte qui contrôle et l'hôte qui est contrôlé sont sécurisées grâce à du chiffrement de bout en bout (il s'appuie notamment sur la librairie sodiumoxide basée sur NaCl pour Rust).

De manière générale, voici les fonctionnalités principales de RuskDesk lorsque l'on se connecte sur une machine :

  • Connexion à partir d'un ID et acceptation manuelle de la connexion ou via un mot de passe
  • Prise en main à distance complète : écran (prise en charge de plusieurs écrans), souris, clavier, audio
  • Transfert de fichiers entre les deux hôtes
  • Historique des connexions récentes et gestion d'une liste de favoris
  • Communication via un chat

B. Les ports utiles pour RustDesk

Pour qu'une connexion soit établie entre deux appareils, ils doivent pouvoir se connecter au serveur RustDesk. Si l'on utilise RustDesk par l'intermédiaire du réseau local uniquement, cela se gère assez facilement, car il n'y aura que les règles de pare-feu au sein même du réseau local à gérer. Par contre, si l'on veut que les machines se connectent au serveur RustDesk depuis n'importe où, il y a deux options pour contacter le serveur RustDesk :

  • Au travers d'une connexion VPN
  • Au travers d'Internet directement, ce qui va impliquer d'ouvrir certains ports

Ce que l'on peut imaginer, c'est monter son propre serveur RustDesk sur un serveur VPS chez OVH ou un autre hébergeur, afin de le rendre accessible facilement, depuis n'importe où.

Peu importe le scénario qui sera retenu, il faut savoir que RustDesk s'appuie sur plusieurs ports pour fonctionner.

  • TCP : 21115, 21116, 21117, 21118, 21119
  • UDP : 21116

Le port 21116 est le seul qui doit être impérativement autorisé en TCP et UDP. Pour être plus précis, et d'après la documentation:

  • 21115 est utilisé pour tester le type de NAT,
  • 21116/UDP est utilisé pour l'enregistrement de l'ID et le service heartbeat
  • 21116/TCP est utilisé pour le service de connexion
  • 21117 est utilisé pour les services de relais
  • 21118 et 21119 sont utilisés pour les clients Web, donc ces deux ports ne sont pas forcément nécessaires

II. Héberger RustDesk sur Debian 11 avec Docker

Sur une machine Debian 11 où Docker est déjà en place, le lancement des deux containers va être assez rapide et facile. On commence par récupérer l'image officielle du container via un classique "docker image pull" comme ceci :

sudo docker image pull rustdesk/rustdesk-server

Ensuite, on va créer un dossier et se positionner à l'intérieur avant de démarrer le container (pour qu'il crée ses données dans ce dossier) :

mkdir /srv/rustdeskserver
cd /srv/rustdeskserver

Il ne reste plus qu'à démarrer les deux containers en s'inspirant des commandes indiquées dans la documentation :

sudo docker run --name hbbs -p 21115:21115 -p 21116:21116 -p 21116:21116/udp -p 21118:21118 -v `pwd`:/root -it --net=host --rm rustdesk/rustdesk-server hbbs -r 192.168.100.14:21117 
sudo docker run --name hbbr -p 21117:21117 -p 21119:21119 -v `pwd`:/root -it --net=host --rm rustdesk/rustdesk-server hbbr

Les commandes ci-dessus vont permettre de voir ce qui se passe au lancement de chaque container. Pour les démarrer en arrière-plan, il suffit d'ajouter l'option "-d" comme ceci :

sudo docker run --name hbbs -d -p 21115:21115 -p 21116:21116 -p 21116:21116/udp -p 21118:21118 -v `pwd`:/root -it --net=host --rm rustdesk/rustdesk-server hbbs -r 192.168.100.14:21117 
sudo docker run --name hbbr -d -p 21117:21117 -p 21119:21119 -v `pwd`:/root -it --net=host --rm rustdesk/rustdesk-server hbbr

A partir de là, les deux containers tournent et nous pouvons le vérifier avec cette commande :

docker ps

Voyons comment mettre en place un serveur RustDesk sur un NAS Synology avant de passer à l'étape des tests.

III. Héberger RustDesk sur un NAS Synology

Pour installer RustDesk sur un NAS Synology, nous allons devoir installer le paquet Docker afin de monter deux containers : hbbs (serveur de rendez-vous et gestion des ID) et hbbr (serveur relais).

A. Installer Docker

Connectez-vous à l'interface DSM afin d'installer Docker, sauf si vous l'avez déjà. Ouvrez le Centre de paquets, recherchez "Docker" et cliquez sur "Installer".

Une fois que c'est fait, lancez l'application afin que l'on puisse monter nos conteneurs.

B. Télécharger l'image RustDesk Server

Au sein de Docker, cliquez sur "Registre" à gauche pour parcourir le catalogue des containers et recherchez "rustdesk-server" afin de trouver l'image officiel :

rustdesk/rustdesk-server

Sélectionnez cette image et cliquez sur "Télécharger".

Une fenêtre apparait, conservez la valeur "latest" et cliquez sur "Sélectionnez".

L'image va être téléchargée (85 Mo) et elle va s'afficher dans l'onglet "Image" de Docker. Nous allons pouvoir créer des containers basés sur cette image.

Synology RustDesk Docker

C. Créer le container hbbs

Pour créer un premier container, double-cliquez sur l'image RustDesk Server dans Docker afin de créer un nouveau container. Pour la première étape nommée "Réseau", sélectionnez "Utiliser le même réseau que Docker Host" et continuez.

Nommez ce container "hbbs", cochez l'option "Activer le redémarrage automatique" afin qu'il démarre automatiquement (et redémarre en cas de crash) et cliquez sur le bouton "Paramètres avancés".

Passez directement à l'onglet "Commande d'exécution" où vous devez configurer l'option "Commande" afin de lancer le serveur RustDesk. Indiquez la valeur suivante :

hbbs -r <votre adresse IP>

Si vous envisagez d'utiliser RustDesk uniquement sur le LAN (ou via un VPN), vous pouvez indiquer l'adresse IP privée de votre NAS. Sinon, il faut indiquer l'adresse IP publique. Voici un exemple :

hbbs -r 192.168.1.149

Cliquez sur "Sauvegarder" et continuez. Cliquez sur le bouton "Ajouter un dossier", par exemple "docker/RustDesk-Server" et puis indiquez "/root" comme chemin d'accès au niveau du container. Dans ce dossier, RustDesk va stocker plusieurs fichiers, notamment sa clé publique.

Cliquez sur "Suivant" puis sur "Effectué" pour terminer la création de ce premier container.


D. Créer le container hbbr

Vous devez créer un second container, basé sur la même image, mais avec le nom "hbbr". Ensuite, indiquez la même configuration que pour le premier container, notamment au niveau du réseau, du dossier, etc... Mais veillez à utiliser simplement cette commande dans l'onglet "Commande d'exécution" :

hbbr

En résumé, cela donne cette configuration pour ce second container :

Quand c'est bon pour vous, cliquez sur "Effectué" pour créer le container. Désormais, nous avons deux containers actifs, comme ceci :

Auto-héberger RustDesk

À partir de là, le serveur RustDesk est en ligne et opérationnel, grâce aux deux containers Docker.

IV. Prise en main à distance avec RustDesk

Pour tester RustDesk en passant par notre serveur, nous avons besoin de deux clients avec RustDesk. Pour rappel, le client RustDesk est téléchargeable directement sur GitHub. Sous Windows, il se présente sous la forme d'un exécutable. Il peut-être installé ou simplement utilisé en mode portable.

Une fois lancé, il faut que l'on configure le client RustDesk pour lui dire d'utiliser notre serveur auto-hébergé. Pour cela, cliquez sur le menu avec les trois points à côté de l'ID, puis sur l'option "ID/Serveur Relais".

Renseignez simplement le champ "Serveur ID" en indiquant l'adresse IP du serveur à contacter (ou le nom de domaine DNS). Cela signifie que vous devez indiquer l'adresse IP privée ou publique selon votre configuration.

Vous devez également renseigner le champ "Key" afin d'indiquer la clé publique générée par votre serveur RustDesk. Sans cela, la connexion ne sera pas chiffrée, mais pourra fonctionner. Quand c'est fait, cliquez sur "Confirmer".

Pour récupérer la valeur de votre clé publique, retournez sur l'interface de DSM (ou le dossier "/srv/rustdeskserver/" si vous utilisez la solution Debian) et à l'aide de l'explorateur de fichiers, accédez au dossier monté dans les containers. Pour ma part, il s'agissait de "docker/RustDesk". Dans ce dossier, téléchargez le fichier "id_ed25519.pub" afin de l'ouvrir et copier-coller la valeur dans le champ "Key" du client RustDesk.

Effectuez la configuration du client RustDesk sur les deux hôtes. Ensuite, vous pouvez tester la connexion pour se connecter d'un hôte A vers un hôte B. Normalement, le client RustDesk doit afficher le statut "Prêt" s'il s'est bien connecté à votre serveur.

Saisissez l'ID de l'hôte distant dans le client RustDesk et validez... La connexion va être établie, et il faudra saisir le mot de passe pour se connecter (accessible depuis l'interface de l'hôte distant). L'alternative consiste à accepter la connexion manuellement, ce qui sera possible si un utilisateur est devant l'ordinateur. D'ailleurs, il vaut mieux utiliser ce principe lorsque l'on se connecte sur un poste d'un utilisateur afin d'avoir son approbation manuelle.

Lorsque l'on se connecte sans avoir renseigné la clé publique dans les paramètres, on voit qu'un bouclier rouge s'affiche en haut de l'interface. Cela indique que la connexion n'est pas sécurisée.

À l'inverse, quand le client est correctement configuré, la connexion est bien sécurisée et chiffrée.

Voilà, vous n'avez plus qu'à profiter de RustDesk !

IV. Configurer automatiquement l'hôte et la clé publique

Plutôt que de configurer chaque machine avec l'adresse IP du serveur et la clé publique, il est possible de jouer sur le nom de l'exécutable. En fait, d'après la documentation officielle, il faut renommer l'exécutable comme ceci (en adaptant avec vos valeurs) :

rustdesk-host=192.168.1.149,key=xYzAbCdEfGhIjKlMn0123.exe

De ce fait, lorsqu'on lance RustDesk et que l'on accède à la section "About RustDesk", on peut voir s'afficher la clé publique et l'hôte. Grâce à cela, RustDesk va utiliser ces informations pour fonctionner et donc on évite de devoir configurer les options de serveur comme nous l'avons fait précédemment.

Gratuite et open source, RustDesk est une solution intéressante qu'il va falloir suivre de près dans les prochains mois, d'autant plus que l'on peut l'auto-hébeger : un avantage en comparaison des autres solutions telles que TeamViewer et AnyDesk. Même si la solution doit encore mûrir pour réellement concurrencer les ténors du marché, c'est un outil à suivre ! Le fait de pouvoir l'héberger permet de prendre la main à distance sur un appareil sans pour autant s'appuyer sur une infrastructure tierce.

N'hésitez pas à tester de votre côté et à me faire un retour en commentaire ! 🙂

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Florian BURNEL

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

Nombre de posts de cet auteur : 5503.Voir tous les posts

33 thoughts on “RustDesk, l’alternative open source à TeamViewer que l’on peut auto-héberger

  • Pas encore testé, mais c’est une excellente alternative.

    Notamment pour les autoentrepreneurs (comme moi ^^) qui n’ont pas forcément les moyens d’acheter une licence TeamViewer pour faire de la PMAD.

    Merci pour cet excellent tutoriel.

    Répondre
  • Question particulière : j’alterne actuellement entre ma maison et mon appartement pour le boulot, et je manipule un pc qui est sur le réseau de mon nas mais :
    – quand je suis à la maison sur le LAN
    – quand je suis suis à mon appart par le net
    peut-on faire une config mix ?

    Répondre
    • Hello,
      Je pense que tu es obligé d’utiliser deux exécutables différents avec l’astuce basée sur le nom du fichier comme expliquée dans l’article, ou au moins pour l’un des deux cas. Mais, pourquoi ne pas utiliser toujours l’adresse IP publique même quand tu es sur le LAN ? Si ta box gère bien le bouclage NAT ça devrait fonctionner 🙂

      Répondre
  • Merci Florian pour le tuto qui tombe pile au moment où je voulais tester le projet. Cela fonctionne plutôt bien et va bien remplacer mon guacamole qui fonctionnait mal avec mon Mac (en vnc).

    Petite info, pour que cela fonctionne sur ma VM chez hetzner il a fallu que j’enlève l’argument –net=host au lancement des containers.

    Et dernière chose, l’astuce de configuration automatique de l’hôte et de la clef publique ne fonctionne pas chez moi car ma clef publique contient des caractères spéciaux qui ne sont pas acceptés dans un nom de fichier… bon c’est pas très grave dans mon cas…

    @+

    Répondre
    • Hello Nico 🙂

      Merci pour ton retour et la petite précision sur l’argument -net.
      Lors de mes différents tests, j’ai eu le même souci pour l’astuce de config automatique mais bizarrement, ça ne semblait pas poser plus de problème que ça car la connexion était bien affichée comme étant chiffrée malgré tout.

      A+
      Florian

      Répondre
    • En fait pour que l’host et la clef publique fonctionnent sur l’executable. Il ne faut pas installer sur la machine. Il faut l’executer avec host + key dans le nom du .exe et là ca fonctionne. Quand tu installes la version sur ta machine c’est pour avoir un accès distant quand tu le souhaites. 😉

      Répondre
  • Bonjour ,

    Merci pour le tuto . J’ai monté un serveur Rustdesk sous Debian pour une utilisation en entreprise . L’application à l’air fluide et facile à prendre en main , le seul hic , c’est que j’aurais aimé ne rendre la prise en main possible seulement pour les techniciens informatiques . Je ne sais pas si il existe une version allégée type « Quicksupport » à destination des utilisateurs ou si il y a possibilité de faire des modifs sur des fichiers de conf pour autoriser nativement que les postes des techniciens (Il y a une option Whitelist dans les paramètres mais je me vois mal configurer sur chaque client la liste des IP autorisées) .

    Répondre
    • Bonjour Abdel,

      J’ai remarqué qu’il peut y avoir une connexion entre deux hôtes seulement s’ils s’appuient sur le même serveur, donc ça permet de bloquer les connexions externes. Par contre, je ne crois pas qu’il y ait une version allégée pour le moment mais ça viendra peut être ! A suivre 🙂

      Répondre
  • Salut Florian,
    Effectivement superbe alternative à TeamViewer, nous sommes en train de le déployer également.
    As tu réussi a faire fonctionner le carnet d’adresses?
    De plus nous essayons de désactiver la « découverte », mais sans succès à ce jour. T’es tu penché sur la question et as tu réussi?
    Malheureusement la doc sur le site de rustdesk n’est pas encore très fournis.

    Répondre
  • Bonjour Florian,
    existe-t-il un script pour faire en sorte que le serveur et le client RustDesk démarrent automatiquement et reste toujours démarrer ?
    La même chose pour générer des ID Rustdesk ?
    (Sur Ubuntu)
    Je n’ai rien pu trouver dans mes recherches.

    Cordialement.

    Répondre
    • Bonjour,
      la solution est trouvée pour que le service RustDesk démarre automatiquement et le reste.
      Il faut créer un « fichier.service » dans « systemd » pour lui configurer un autostart. (d’autres solutions peuvent être mises en place, comme des scripts, etc.)

      Il ne me manque plus que la génération d’ID via la ligne de commande ou autre.
      Si quelqu’un a une idée…

      Répondre
  • Bonjour,

    Idem pour le carnet d’adresses, comment le créer ?
    Vu un petit bug ce matin quand j’écris â il met )â, idem chez vous ?
    Pas de CTRL+ALT+SUPP apparemment.
    Sinon, ça marche bien, je l’ai comparé à Teamviwer.

    Cordialement

    Répondre
  • Bonjour,

    Testé en local pour le moment et fonctionne parfaitement aussi , mais avant de remplacé un TMW il faudrait effectivement que le carnet d’adresse fonctionne.

    Quelqu’un a des infos sur le sujet ?

    Répondre
  • Bonjour, je dois configurer les filtres des ports sur mon firewall, comment utiliser deux protocoles TCP et UDP sur le même port 21116 ? Car il m’indique que ce port est déjà utilisé par le protocole TCP ?😅

    Cordialement,

    Répondre
  • Bonjour,
    Merci pour cet excellent tuto et bravo.
    Juste une question :
    Dans le conteneur hbbr au niveau de la commande d’exécution peut-on mettre un FQDN plutôt que l’adresse IP Publique ?
    En local, sur le Lan cela fonctionne mais pas en externe, et chez moi je n’ai pas une adresse publique fixe.
    Merci a tous si vous avez une solution.

    Répondre
    • Réponse a moi même, avec le FQDN cela foctionne

      Répondre
  • Bonjour Florian et bonjour à tous.
    Merci pour ce tuto.
    Je cherche à répondre à une problématique, je vous donne mon lexique :
    Server RD > Le serveur RustDesk
    Agents RD > Les machines que l’on souhaite contrôler
    Clients RD > Les machines depuis lesquelles je souhaite contrôler les agents

    Je souhaite autoriser uniquement les clients de l’équipe de maintenance à se connecter au agents.
    Le client et l’agent utilisent les mêmes ports pour emmètre ou recevoir une connexion, comment faire en sorte que la connexion aux agents ne soient possible que depuis un seul plan IP, sans le définir sur chaque agent ?

    Avez vous une idée ?

    Brice – SPOC

    Répondre
    • Bonjour TheNerdCat,
      j’ai testé de prendre la main sur la version quicksupport (+ sciter.dll) et j’ai un message comme quoi il ne trouve pas l’identifiant.
      Avez vous une idée, svp ?
      Merci d’avance.

      Répondre
      • Bonjour Philippe,
        Vous utilisez votre propre serveur Relais Rustdesk ?
        Si c’est le cas, en effet la version QS se base uniquement sur les serveurs officiels de Rustdesk.

        dans %AppData%\RustDesk – QuickSupport v1.0\config, il y a un fichier .toml
        vous pouvez l’éditer pour préciser votre propre serveur Relais

        exemple :

        remote_id = «  »
        size = [307, 117, 516, 338]
        rendezvous_server = « MON_SERVEUR_RELAIS »
        nat_type = 1
        serial = 3

        [options]
        key = « LA_CLEF_DE_MON_SERVEUR_RELAIS »
        custom-rendezvous-server = « MON_SERVEUR_RELAIS »
        relay-server = « MON_SERVEUR_RELAIS »

        Répondre
  • Il y aurait la possibilité de modifier quelque chose pour que ce RustDesk QS puisse utiliser nos propres identifiants ?

    Répondre
  • Bonjour,
    J’ai aussi découvert cet outil qui a bien fonctionné qq jours mais depuis ce matin il me sort une erreur lors de la connexion : deadline has elapsed.
    J’utilise le serveur public et teste avec 2 postes sous windows 10.
    J’ai vu 2 discussions sur le forum de rustdesk mais pas vu de solution.
    Je n’ai pas essayé de ré-installer.
    Bonne Année à tous.

    Répondre
  • Bonjour à tous, et merci Florian pour ce tuto.
    J’ai mis en place Rustdesk sur mon NAS synology (DS1618+) avec Docker : le tuto était très explicite, 1ère fois que j’utilisais Docker, tout a été bouclé très vite (je ne suis pas un professionnel de l’informatique).
    Je l’ai testé:
    * Sur mon LAN –> cela marche très bien
    * En accès OPENVPN en mode client – serveur via mon routeur synology RT2600AC (VPN) et une ligne 4G+ (pour sortir du réseau) : un peu de latence, mais c’était acceptable. La latence était plus dûe à la ligne 4G à mon avis.
    * En accès VPN site à site avec 2 RT2600AC (Lille – Strasbourg ), c’était très bien : réactivité, audio et vidéo, très peu de latence (j’ai la fibre sur les 2 sites).
    Bref, cela permet d’intervenir sur une longue durée pour du dépannage, sans se faire sortir par les time-out de Anydesk ou de Teamviewer.

    C’est donc une bonne solution, je trouve.
    La fonction carnet d’adresse n’a pas été développée jusqu’au bout, je n’en ai pas l’utilité aujourd’hui, cela relève plus du confort.
    Merci encore

    Répondre
  • Bonjour Florian,
    Merci pour le tuto, toujours clairement expliqué mais je débute et donc il y a quelques points que je ne visualise pas bien…
    Est-ce qu’il y a moyen de prendre la main sur l’autre pc avec les droits administrateur ?
    Et si il faut procéder à un redémarrage de la machine après modifications, est-ce qu’on peut reprendre la main sans intervention de l’utilisateur?
    Merci d’avance, à bientôt

    Répondre
  • Bonjour Florian, j’ai effectuer les manipulations comme sur ta vidéo, en local cela fonctionne parfaitement, mais dès que je le fais avec l’adresse ip publique cela ne fonctionne pas, je n’arrive pas à voir ou cela coince

    Répondre
  • Bonjour Florian merci pour ce tuto, très claire comme toujours !

    J’ai installé le serveur dans une VM Proxmox, tout fonctionne !

    Merci
    John

    Répondre
  • Combien de connexion en même temps si c’est moi qui héberge mon serveur sur mon synology.

    Répondre

Répondre à Steven Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.