Pourquoi self-héberger son serveur de bureau à distance
Les solutions commerciales comme TeamViewer ou AnyDesk ont un point commun : chaque connexion passe par leur infrastructure de relais, quelle que soit la distance réelle entre les deux machines. Cela pose trois problèmes concrets.
Confidentialité et conformité. Les données transitent par des serveurs tiers soumis à la législation de leur pays d'hébergement. Pour les prestataires IT qui accèdent à des systèmes financiers, médicaux ou juridiques, cette délégation implicite peut invalider un accord de conformité (RGPD, ISO 27001, HIPAA). RustDesk self-hosted élimine cette dépendance : le trafic chiffré reste dans votre datacenter.
Historique de vulnérabilités. TeamViewer a subi plusieurs incidents notables — en 2016, des milliers de comptes ont été compromis par credential stuffing ; en 2024, une intrusion dans l'environnement corporate a été attribuée à un groupe APT. Ces incidents ne mettent pas en cause le protocole, mais soulignent que dépendre d'un tiers, c'est dépendre de sa surface d'attaque.
Coût des licences. TeamViewer Business démarre à plus de 600 €/an pour un seul utilisateur simultané. AnyDesk est moins cher mais reste sur un modèle par siège. RustDesk self-hosted réduit le coût à celui de votre VPS — un ServOrbit à partir de 99 DH/mois suffit pour toute une équipe.
Ce que RustDesk self-hosted vous offre
- Aucune limite de session — pas de licence par siège ni de quota de connexions simultanées ; votre serveur sert autant d'utilisateurs que votre VPS peut en absorber
- Chiffrement bout-en-bout garanti — courbe Ed25519 pour l'échange de clés, ChaCha20-Poly1305 pour le flux vidéo et les entrées clavier/souris : la clé publique de votre serveur est intégrée au client, ce qui rend l'interception structurellement impossible
- Latence maîtrisée — votre relais est dans le datacenter de votre choix ; en choisissant la région la plus proche de vos équipes, le RTT est systématiquement inférieur à celui d'un relais SaaS générrique basé en Europe du Nord
- Clients multiplatformes — Windows, macOS, Linux, Android, iOS et navigateur web depuis un seul serveur central, sans configuration différente par plateforme
- Mode ID personnalisé — assignez des identifiants mémorables (
SERVEUR-DB-01,LAPTOP-ALICE) au lieu des ID numériques aléatoires générés par défaut - API REST intégrée — RustDesk Server Pro expose une API REST qui permet d'interroger l'état des connexions, de lister les machines enregistrées et d'automatiser le provisionnement via vos propres scripts ou un CMDB
- Audit log des sessions — chaque connexion, déconnexion et transfert de fichier est horodaté et journalisé côté serveur ; indispensable pour les environnements soumis à des exigences de traçabilité
Architecture RustDesk : hbbs et hbbr
RustDesk sépare le rôle de signalisation du rôle de relais en deux processus distincts.
hbbs — le serveur de rendez-vous (ID Server). C'est le point d'entrée. Chaque client RustDesk qui démarre s'y enregistre avec un identifiant numérique (ou personnalisé). Quand une connexion est initiée, les deux parties se contactent via hbbs pour échanger leurs adresses IP et tenter une connexion directe P2P. hbbs écoute sur les ports TCP 21115 et 21116, ainsi que UDP 21116.
hbbr — le serveur relais (Relay Server). Si la connexion P2P échoue (NAT symétrique, pare-feu restrictif), le trafic est relayé via hbbr. Le relais ne voit que des flux chiffrés — il ne peut pas lire le contenu. hbbr écoute sur le port TCP 21117.
Flux d'une connexion. La machine A contacte hbbs en TCP pour obtenir l'adresse de la machine B. Les deux machines tentent une connexion directe UDP (hole punching). Si elle réussit, hbbr n'est pas impliqué et la latence est minimale. Si elle échoue, hbbs fournit à A l'adresse de hbbr pour relayer — avec un léger surcoût de quelques millisecondes. Dans la pratique, P2P réussit sur la majorité des réseaux domestiques et d'entreprise qui n'ont pas de NAT strict.
Prérequis VPS
Ressources minimales. 1 Go de RAM et 1 vCPU suffisent jusqu'à environ 20 connexions simultanées en mode relais. Au-delà, le facteur limitant est la bande passante : un flux Full HD encode à environ 2-4 Mbit/s. Pour 50 connexions simultanées en relay, prévoyez 2 vCPU, 2 Go de RAM et un VPS avec un débit garanti d'au moins 200 Mbit/s.
Ports à ouvrir.
- TCP 21115 — négociation NAT
- TCP 21116 — enregistrement des ID
- UDP 21116 — hole punching P2P
- TCP 21117 — flux relayé
- TCP 21118 et 21119 — client web (optionnel)
- TCP 443 — interface admin HTTPS (si activée)
Logiciels requis. Docker Engine 24+ et Docker Compose v2 (docker compose sans tiret). Un nom de domaine ou sous-domaine est recommandé pour exposer l'interface admin derrière TLS — sinon les connexions à la GUI se font en HTTP clair.
Déployer RustDesk Server sur VPS
Créer le répertoire et le fichier docker-compose.yml
Créez la structure de répertoires et le fichier Compose :
mkdir -p /opt/rustdesk/data cd /opt/rustdeskContenu du fichier
docker-compose.yml:services: hbbs: image: rustdesk/rustdesk-server:latest command: hbbs ports: - "21115:21115" - "21116:21116" - "21116:21116/udp" - "21118:21118" volumes: - ./data:/root restart: unless-stopped depends_on: - hbbr hbbr: image: rustdesk/rustdesk-server:latest command: hbbr ports: - "21117:21117" - "21119:21119" volumes: - ./data:/root restart: unless-stoppedLe volume partagé
./datagarantit quehbbsethbbrutilisent la même paire de clés générée au premier démarrage.Démarrer les conteneurs et récupérer les clés
Lancez les deux services en arrière-plan :
docker compose up -dAu premier démarrage,
hbbsgénère automatiquement une paire de clés Ed25519 dans./data/. Récupérez la clé publique :cat /opt/rustdesk/data/id_ed25519.pubNotez cette valeur — vous en aurez besoin pour configurer chaque client. Sans elle, les clients refuseront de se connecter à votre serveur. Conservez aussi
id_ed25519(clé privée) en lieu sûr ; si elle est compromise, tous les clients devront être reconfigurés avec une nouvelle clé.Configurer le pare-feu (ports TCP/UDP)
Ouvrez les ports nécessaires dans
ufw:ufw allow 21115/tcp ufw allow 21116/tcp ufw allow 21116/udp ufw allow 21117/tcp ufw allow 21118/tcp ufw allow 21119/tcp ufw reloadSi votre VPS est également protégé par un pare-feu réseau dans le panneau ServOrbit, appliquez les mêmes règles à ce niveau. Vérifiez ensuite que les ports sont bien en écoute :
ss -tlnup | grep -E '2111[5-9]'Exposer l'interface admin derrière un reverse proxy HTTPS
RustDesk Server Pro propose une interface web d'administration sur le port 21114 (HTTP). Pour l'exposer en HTTPS, ajoutez nginx comme reverse proxy dans votre
docker-compose.ymlou dans une configuration nginx existante.Exemple de vhost nginx minimal pour
rustdesk.votre-domaine.com:server { listen 443 ssl; server_name rustdesk.votre-domaine.com; ssl_certificate /etc/letsencrypt/live/rustdesk.votre-domaine.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/rustdesk.votre-domaine.com/privkey.pem; location / { proxy_pass http://127.0.0.1:21114; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }Obtenez le certificat avec Certbot :
certbot --nginx -d rustdesk.votre-domaine.comConfigurer les clients desktop (Windows, macOS, Linux)
Téléchargez le client RustDesk depuis [rustdesk.com](https://rustdesk.com) et ouvrez les paramètres réseau (icône engrenage → Réseau). Renseignez :
- Serveur ID : adresse IP ou nom de domaine de votre VPS
- Serveur Relay : même valeur
- Clé : la valeur copiée depuisid_ed25519.pubValidez. L'indicateur de connexion passe au vert si le serveur est joignable et la clé correcte. Dès cet instant, aucune tentative de connexion ne passe par les serveurs publics RustDesk.
Configurer les clients mobiles (Android et iOS)
Sur Android, installez RustDesk depuis le Play Store ou en APK direct (utile si le Play Store est restreint sur certains appareils d'entreprise). Sur iOS, RustDesk est disponible sur l'App Store.
Dans les deux cas, accédez à Paramètres → ID/Relay Server et renseignez les mêmes valeurs que pour le client desktop : adresse du serveur et clé publique. La clé peut être partagée via QR code depuis l'interface admin de RustDesk Server Pro, ce qui simplifie le déploiement en masse sur flotte mobile.
Tester une connexion bout en bout
Sur deux machines configurées avec votre serveur, relevez l'identifiant affiché sur la machine cible. Depuis la machine source, entrez cet identifiant dans le champ de connexion RustDesk et initiez la session.
Vérifiez dans les logs que la connexion passe bien par votre infrastructure :
docker logs rustdesk-hbbr-1 --tail 20Une ligne contenant
[RELAY]indique que le relais est utilisé (NAT strict). Une ligne[DIRECT]ou l'absence de ligne dans les logs dehbbrindique une connexion P2P directe — idéale pour la latence.
Configurer TLS pour les connexions sécurisées
Par défaut, les flux RustDesk sont chiffrés bout-en-bout avec ChaCha20-Poly1305 — TLS supplémentaire n'est pas requis pour les sessions de bureau à distance elles-mêmes. En revanche, l'interface admin (port 21114) et l'API REST tournent en HTTP clair si vous ne les protégez pas.
Option 1 : Certbot + nginx (recommandé). Comme vu à l'étape 4, nginx agit en reverse proxy devant le port 21114. Certbot renouvelle le certificat automatiquement via un timer systemd.
Option 2 : Traefik comme edge proxy. Si vous utilisez déjà Traefik pour d'autres services sur le même VPS, ajoutez simplement des labels au service hbbr dans Compose :
labels:
- "traefik.enable=true"
- "traefik.http.routers.rustdesk-admin.rule=Host(`rustdesk.votre-domaine.com`)"
- "traefik.http.routers.rustdesk-admin.tls.certresolver=letsencrypt"
- "traefik.http.services.rustdesk-admin.loadbalancer.server.port=21114"Ce qui reste en clair par conception. Les ports 21115-21119 ne passent pas par HTTPS car ils utilisent leurs propres protocoles binaires. Le chiffrement de ces flux est assuré par les clés Ed25519 et ChaCha20 — pas par TLS. Ne tentez pas de forcer HTTPS sur ces ports.
Activer l'authentification et le contrôle d'accès
La version open source de RustDesk Server ne propose pas d'interface d'authentification native — tout client connaissant votre clé publique peut se connecter à une machine enregistrée si celle-ci accepte la demande. RustDesk Server Pro (auto-hébergeable, gratuit jusqu'à 20 utilisateurs) ajoute plusieurs couches de contrôle.
Comptes utilisateurs et groupes. L'interface admin permet de créer des comptes nommés, de les regrouper et de définir des politiques d'accès par groupe. Un technicien peut avoir accès uniquement aux machines du groupe « Infrastructure », pas aux postes RH.
Approbation de connexion. Chaque machine peut être configurée pour demander une confirmation physique à l'utilisateur local avant d'autoriser la prise en main — le panneau « Accepter la connexion » apparaît sur l'écran de la machine cible.
Audit trail complet. Chaque événement (connexion initiée, acceptée, refusée, durée, transfert de fichier) est enregistré avec l'identité de l'initiateur et l'horodatage. Les logs sont exportables en CSV depuis l'interface admin.
Désactiver les serveurs publics. Pour forcer l'utilisation exclusive de votre serveur — sans repli sur les relais publics RustDesk en cas d'indisponibilité — ajoutez l'option --key avec votre clé privée dans la commande hbbs. Les clients configurés avec votre clé publique refuseront alors tout serveur alternatif, même le serveur officiel RustDesk.
Optimiser la qualité d'image et la performance
RustDesk utilise par défaut son propre codec vidéo (VP9 ou H.264 selon la plateforme) avec une qualité adaptative basée sur la bande passante détectée. Plusieurs leviers permettent d'affiner ce comportement.
Qualité d'image. Dans les paramètres du client, « Qualité image » peut être réglée sur Bas, Moyen, Élevé ou Personnalisé. En entreprise sur un réseau local ou un VPS proche géographiquement, « Élevé » est utilisable sans saturer la bande passante. Sur une connexion mobile ou longue distance, « Moyen » réduit la latence perçue.
Codec. RustDesk sélectionne automatiquement le codec le plus adapté : H.265 si les deux extrémités ont un encodage/décodage matériel, VP9 sinon. Sur un VPS sans GPU, VP9 est le choix par défaut — il est raisonnable en CPU pour les flux bureautiques. Évitez de forcer H.264 sur un VPS à faible CPU si vous avez plusieurs connexions simultanées.
P2P vs relais. Une connexion P2P directe est toujours préférable : elle évite le saut supplémentaire via hbbr et améliore la latence en supprimant le relais intermédiaire. Si vos utilisateurs se connectent depuis le même réseau local que la machine cible, vérifiez que le pare-feu ne bloque pas les connexions UDP directes entre postes — RustDesk tentera d'abord P2P avant de passer au relais.
RustDesk vs TeamViewer vs AnyDesk vs Guacamole
Faites défiler le tableau
| Critère | RustDesk (self-hosted) | TeamViewer | AnyDesk | Guacamole |
|---|---|---|---|---|
| Modèle d'hébergement | Self-hosted (VPS) | SaaS (cloud vendor) | SaaS (cloud vendor) | Self-hosted (serveur web) |
| Coût de licence | Gratuit (OSS) / Pro payant | À partir de 600 €/an/utilisateur | À partir de 180 €/an/utilisateur | Gratuit (Apache 2.0) |
| Protocole | Propriétaire chiffré (Ed25519 + ChaCha20) | Propriétaire (RDP/VNC hybride) | DeskRT (codec propriétaire) | VNC / RDP / SSH via navigateur |
| Connexion P2P | Oui (avec fallback relais) | Non (toujours via cloud) | Oui (avec fallback) | Non (proxy central) |
| Clients mobiles natifs | Android + iOS natifs | Android + iOS natifs | Android + iOS natifs | Navigateur uniquement |
| Audit log | Oui (Pro) | Oui (Business+) | Oui (Business+) | Limité (logs serveur bruts) |
| API REST | Oui (Pro) | Oui (payant) | Non (API tierce) | Oui (REST partielle) |
| Souveraineté données | Totale (votre infra) | Nulle (cloud TeamViewer) | Partielle (relais AnyDesk) | Totale (votre infra) |
Déploiement en entreprise : provisionner les clients en masse
RustDesk supporte la configuration automatique via un fichier JSON embarqué dans l'exécutable client. Lors du build ou du packaging pour votre flotte, placez un fichier RustDesk2.toml dans le répertoire de configuration avec vos valeurs :
relay-server = "votre-vps.exemple.com"
id-server = "votre-vps.exemple.com"
key = "<votre_clé_publique_ed25519>"Pour Windows, ce fichier va dans %APPDATA%\RustDesk\config\. Pour Linux, dans ~/.config/rustdesk/. Vous pouvez déployer cette configuration via votre outil de gestion de flotte (Ansible, Intune, Puppet) sans interaction utilisateur. La clé publique et l'adresse serveur sont préchargées — l'utilisateur installe RustDesk et se retrouve directement connecté à votre infrastructure.
Surveiller et maintenir le serveur
Métriques Docker. Surveillez la consommation en temps réel avec docker stats — un pic CPU sur hbbr indique un nombre inhabituellement élevé de connexions relayées. Si la moyenne dépasse 80 % sur plusieurs minutes, envisagez d'augmenter le vCPU ou de vérifier si des connexions bloquées génèrent du retry en boucle.
Rotation des logs. Les conteneurs écrivent dans stdout/stderr, gérés par le démon Docker. Ajoutez une politique de rotation dans docker-compose.yml pour éviter que les logs ne saturent le disque :
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "5"Mise à jour de l'image. RustDesk publie des nouvelles versions régulièrement. Pour mettre à jour sans interruption de service perceptible :
docker compose pull
docker compose up -dDocker remplace les conteneurs un par un. Les sessions en cours via hbbr sont coupées pendant le redémarrage (quelques secondes) — préférez les mises à jour en heures creuses. Les clés dans ./data/ sont préservées — aucune reconfiguration des clients n'est nécessaire.
Résoudre les problèmes courants
Connexion impossible, ID non trouvé. Vérifiez que hbbs tourne (docker ps) et que les ports 21115-21116 TCP et 21116 UDP sont joignables depuis l'extérieur : nc -vz <ip-vps> 21116. Si le test échoue, le pare-feu réseau (ufw ou règle VPS) bloque le port.
« Clé incorrecte » côté client. La clé affichée dans le client ne correspond pas à id_ed25519.pub sur le serveur. Relisez la valeur exacte avec cat /opt/rustdesk/data/id_ed25519.pub et reconfigurerez le client — attention aux espaces ou retours à la ligne parasites lors du copier-coller.
Toujours en mode relay, jamais P2P. Le hole punching UDP échoue si l'un des deux réseaux utilise un NAT symétrique (fréquent sur certains réseaux mobiles 4G/5G et VPN d'entreprise). Ce n'est pas un bug — le relais fonctionne correctement, avec une latence légèrement supérieure. Pour forcer le diagnostic, comparez les logs de hbbr avec et sans VPN actif côté client.
L'interface admin est inaccessible. Le port 21114 n'est pas exposé dans le docker-compose.yml de base — il faut l'ajouter explicitement ou passer par le reverse proxy nginx vu à l'étape 4. Vérifiez aussi que vous utilisez bien l'image rustdesk-server-pro (la version open source ne propose pas d'interface admin).
Mise à jour de l'image sans régénérer les clés. Après docker compose pull && docker compose up -d, vérifiez que le fichier ./data/id_ed25519.pub n'a pas changé — il ne devrait pas, mais une corruption de volume peut dans de rares cas regénérer la paire. Si la clé a changé, tous les clients devront être reconfigurés.
