Procédure de Migration RustDesk — VLAN SRV vers VLAN DMZ
Guide pour migrer un serveur RustDesk (hbbs et hbbr) d'un VLAN SRV à un VLAN DMZ
Informations de référence
Ancien réseau : VLAN SRV — 10.192.193.0/24
Nouvelle IP : VLAN DMZ — 10.192.194.0/24
IP actuelle : 10.192.193.110
Nouvelle IP : 10.192.194.110 (à adapter selon le plan d'adressage)
Passerelle DMZ : 10.192.194.1
Services : hbbs (ports 21115, 21116 TCP/UDP) + hbbr (port 21117 TCP)
Répertoire : /opt/rustdesk-server
Toute la procédure est réalisée en production. Chaque étape doit être validée avant de passer à la suivante. Prévoir une fenêtre de maintenance.
PARTIE 1 — Préparation
1.1 Vérification de l'état courant des services
systemctl status hbbs hbbr
ss -tlnup | grep -E '2111[5-7]'
ps aux | grep -E 'hbbs|hbbr'
Attendu : les deux services active (running), ports 21115, 21116 et 21117 en écoute.
1.2 Récupération de la clé publique RustDesk
cat /opt/rustdesk-server/id_ed25519.pub
Copier et conserver cette clé. Elle sera distribuée aux clients. Si elle ne change pas, les clients existants n'ont pas besoin d'être reconfigurés côté clé.
ls -lh /opt/rustdesk-server/
Vérifier la présence de id_ed25519 et id_ed25519.pub.
1.3 Récupération de la configuration réseau actuelle
ip a
ip route
cat /etc/network/interfaces
Noter :
- Nom de l'interface réseau (ex : ens18, eth0)
- IP actuelle : 10.192.193.110
- Masque : 255.255.255.0 (/24)
- Passerelle actuelle : 10.192.193.1
1.4 Récupération des paramètres des services systemd
cat /etc/systemd/system/hbbs.service
cat /etc/systemd/system/hbbr.service
Noter la ligne ExecStart, notamment l'argument -r de hbbs qui contient l'IP ou le nom du serveur relay.
1.5 Sauvegarde complète des fichiers critiques
mkdir -p /root/backup-rustdesk-migration
cp -r /opt/rustdesk-server /root/backup-rustdesk-migration/
cp /etc/systemd/system/hbbs.service /root/backup-rustdesk-migration/
cp /etc/systemd/system/hbbr.service /root/backup-rustdesk-migration/
cp /etc/network/interfaces /root/backup-rustdesk-migration/interfaces.bak
ls -lh /root/backup-rustdesk-migration/
1.6 Vérification de l'accès SSH avant coupure réseau
Depuis une machine cliente, confirmer que la session SSH est active et qu'un accès console (iDRAC, KVM, accès physique, console OPNsense) est disponible en cas de perte de connexion SSH après le changement d'IP.
PARTIE 2 — Migration réseau côté serveur
2.1 Modification de l'adresse IP
nano /etc/network/interfaces
Contenu attendu avant modification :
auto ens18
iface ens18 inet static
address 10.192.193.110
netmask 255.255.255.0
gateway 10.192.193.1
Contenu après modification :
auto ens18
iface ens18 inet static
address 10.192.194.110
netmask 255.255.255.0
gateway 10.192.194.1
Remplacer ens18 par le nom réel de l'interface identifié à l'étape 1.3.
2.2 Modification des DNS si nécessaire
nano /etc/resolv.conf
Vérifier que les serveurs DNS sont accessibles depuis le VLAN DMZ. Adapter si nécessaire.
2.3 Application du changement réseau
systemctl restart networking
Si la commande ci-dessus interrompt la session SSH, se reconnecter sur la nouvelle IP :
ssh user@10.192.194.110
Si la reconnexion échoue, utiliser la console d'accès physique ou KVM.
2.4 Vérification de la nouvelle configuration réseau
ip a | grep 10.192.194
Attendu : inet 10.192.194.110/24
ip route
Attendu : route par défaut via 10.192.194.1
ping -c 4 10.192.194.1
Attendu : réponses sans perte de paquet.
ping -c 4 8.8.8.8
Vérifier l'accès à Internet depuis la DMZ (selon les règles OPNsense).
PARTIE 3 — Adaptation de RustDesk
3.1 Vérification de l'impact du paramètre -r
Le paramètre -r dans la commande hbbs indique aux clients l'adresse du serveur relay (hbbr). Si l'ancienne IP y est codée en dur, les clients ne pourront pas établir de session relay.
cat /etc/systemd/system/hbbs.service | grep ExecStart
Exemple de sortie actuelle :
ExecStart=/opt/rustdesk-server/hbbs -r 10.192.193.110
3.2 Modification du fichier unit hbbs
nano /etc/systemd/system/hbbs.service
Modifier la ligne ExecStart :
Avant :
ExecStart=/opt/rustdesk-server/hbbs -r 10.192.193.110
Après :
ExecStart=/opt/rustdesk-server/hbbs -r 10.192.194.110
Si un nom DNS est utilisé à la place d'une IP, conserver le nom de domaine et mettre à jour l'enregistrement DNS.
3.3 Vérification du fichier unit hbbr
cat /etc/systemd/system/hbbr.service
hbbr n'utilise généralement pas de paramètre -r. Vérifier que ExecStart ne contient pas d'ancienne IP.
3.4 Rechargement de la configuration systemd et redémarrage des services
systemctl daemon-reload
systemctl restart hbbs hbbr
systemctl status hbbs hbbr
Attendu : Active: active (running) pour les deux services.
3.5 Vérification des ports en écoute sur la nouvelle IP
ss -tlnup | grep -E '2111[5-7]'
Attendu :
tcp LISTEN 0 128 0.0.0.0:21115 ... hbbs
tcp LISTEN 0 128 0.0.0.0:21116 ... hbbs
tcp LISTEN 0 128 0.0.0.0:21117 ... hbbr
ss -ulnup | grep 21116
Attendu : port 21116 UDP en écoute (hbbs utilise UDP pour le NAT traversal).
3.6 Vérification des logs de démarrage
journalctl -u hbbs -n 30 --no-pager
journalctl -u hbbr -n 30 --no-pager
Vérifier l'absence d'erreur liée à l'IP ou aux ports.
PARTIE 4 — Configuration OPNsense
4.1 Accès à l'interface OPNsense
Se connecter à l'interface web OPNsense via le navigateur.
Chemin des règles pare-feu :
Firewall > Rules > [Interface du VLAN source des clients]
4.2 Règles à créer — VLAN Clients vers VLAN DMZ
Créer les règles suivantes sur l'interface du VLAN clients (ex : VLAN_USERS ou interface correspondante) :
Règle 1 — TCP port 21115 (hbbs — enregistrement ID)
Action : Pass
Interface : VLAN_CLIENTS (interface source)
Protocol : TCP
Source : VLAN_CLIENTS net
Dest. : 10.192.194.110
Dest port : 21115
Desc. : RustDesk hbbs TCP 21115
Règle 2 — TCP/UDP port 21116 (hbbs — NAT traversal)
Action : Pass
Interface : VLAN_CLIENTS
Protocol : TCP/UDP
Source : VLAN_CLIENTS net
Dest. : 10.192.194.110
Dest port : 21116
Desc. : RustDesk hbbs TCP+UDP 21116
Règle 3 — TCP port 21117 (hbbr — relay)
Action : Pass
Interface : VLAN_CLIENTS
Protocol : TCP
Source : VLAN_CLIENTS net
Dest. : 10.192.194.110
Dest port : 21117
Desc. : RustDesk hbbr TCP 21117
4.3 Suppression ou désactivation des anciennes règles
Repérer les règles pointant vers 10.192.193.110 et les désactiver (ne pas supprimer immédiatement — conserver pendant la phase de test).
4.4 Vérification NAT (si applicable)
Si le serveur RustDesk était accessible depuis Internet via une redirection NAT sur l'ancienne IP :
Chemin :
Firewall > NAT > Port Forward
Mettre à jour les règles de redirection :
Ancienne destination interne : 10.192.193.110
Nouvelle destination interne : 10.192.194.110
Vérifier également les règles NAT outbound si le serveur DMZ doit sortir sur Internet avec une IP publique spécifique.
4.5 Application des règles
Cliquer sur Apply changes dans OPNsense après chaque modification.
4.6 Tests de flux inter-VLAN depuis OPNsense
Depuis l'outil de diagnostic OPNsense :
Interfaces > Diagnostics > Ping
Tester depuis l'interface DMZ vers l'IP du serveur :
ping 10.192.194.110
Vérifier les logs du pare-feu :
Firewall > Log Files > Live View
Filtrer sur 10.192.194.110 pour observer les flux acceptés ou rejetés en temps réel.
PARTIE 5 — Mise à jour des clients
5.1 Fichiers de configuration RustDesk côté client
Les fichiers de configuration RustDesk se trouvent selon le système :
Windows :
%APPDATA%\RustDesk\config\RustDesk.toml
%APPDATA%\RustDesk\config\RustDesk2.toml
Linux :
~/.config/rustdesk/RustDesk.toml
~/.config/rustdesk/RustDesk2.toml
5.2 Contenu à modifier dans RustDesk.toml
Ouvrir RustDesk.toml et localiser les lignes suivantes :
Avant :
rendezvous_server = '10.192.193.110'
Après :
rendezvous_server = '10.192.194.110'
Vérifier également RustDesk2.toml :
[options]
custom-rendezvous-server = '10.192.194.110'
relay-server = '10.192.194.110'
key = '<clé_publique_copiée_étape_1.2>'
5.3 Impact sur la clé publique
Si les fichiers /opt/rustdesk-server/id_ed25519 et id_ed25519.pub n'ont pas été régénérés, la clé publique est identique à l'ancienne. Les clients n'ont pas besoin de modifier la clé, uniquement l'adresse IP du serveur.
SI les clés ont été régénérées (ex : restauration depuis zéro) : redistribuer la nouvelle clé publique à tous les clients dans le champ key de RustDesk2.toml.
5.4 Déploiement par script (Windows)
Créer un script PowerShell de mise à jour de la configuration :
$configPath = "$env:APPDATA\RustDesk\config\RustDesk.toml"
$config2Path = "$env:APPDATA\RustDesk\config\RustDesk2.toml"
(Get-Content $configPath) -replace '10\.192\.193\.110', '10.192.194.110' |
Set-Content $configPath
(Get-Content $config2Path) -replace '10\.192\.193\.110', '10.192.194.110' |
Set-Content $config2Path
Write-Host "Configuration RustDesk mise a jour."
Déployer ce script via GPO (stratégie d'ordinateur > Scripts > Démarrage) ou via un outil de déploiement.
5.5 Déploiement par GPO — fichier de configuration
Si la configuration est déployée par GPO via un fichier partagé :
1. Mettre à jour le fichier modèle sur le partage réseau
2. Forcer la mise à jour des GPO sur les clients :
gpupdate /force
5.6 Redémarrage du client RustDesk
Après modification des fichiers de configuration, redémarrer le service ou l'application RustDesk sur chaque poste client.
Windows (service) :
net stop RustDesk
net start RustDesk
Linux :
systemctl restart rustdesk 2>/dev/null || pkill rustdesk && rustdesk &
PARTIE 6 — Tests complets
6.1 Test de connectivité réseau depuis un client vers la nouvelle IP
ping 10.192.194.110
Attendu : réponses sans perte.
Si ping bloqué (règle ICMP absente dans OPNsense), tester directement les ports.
6.2 Test des ports RustDesk depuis un client
Depuis un poste Windows (PowerShell) :
Test-NetConnection -ComputerName 10.192.194.110 -Port 21115
Test-NetConnection -ComputerName 10.192.194.110 -Port 21116
Test-NetConnection -ComputerName 10.192.194.110 -Port 21117
Attendu : TcpTestSucceeded : True pour les trois ports.
Depuis un poste Linux :
nc -zv 10.192.194.110 21115
nc -zv 10.192.194.110 21116
nc -zv 10.192.194.110 21117
Attendu : Connection to 10.192.194.110 2111X port [tcp] succeeded
6.3 Test depuis le serveur RustDesk lui-même
ss -tlnup | grep -E '2111[5-7]'
nc -zv 127.0.0.1 21115
nc -zv 127.0.0.1 21116
nc -zv 127.0.0.1 21117
6.4 Test de connexion RustDesk client vers serveur
Sur un poste client, ouvrir RustDesk et observer le statut de connexion au serveur :
Statut attendu : "Prêt" (Ready) avec point vert
Statut anormal : "Serveur non disponible" ou point rouge
Tenter une prise en main à distance d'un poste cible pour valider le flux relay complet.
6.5 Vérification des logs serveur pendant le test
Sur le serveur, observer les connexions en temps réel :
journalctl -u hbbs -f
journalctl -u hbbr -f
Attendu : apparition de lignes de connexion lors des tests clients, sans erreur.
6.6 Vérification des logs pare-feu OPNsense
Firewall > Log Files > Live View
Filtrer : destination = 10.192.194.110
Confirmer que les flux sur les ports 21115, 21116, 21117 sont acceptés (action pass).
PARTIE 7 — Troubleshooting
7.1 Service actif mais inaccessible depuis les clients
Vérifier que les services écoutent sur toutes les interfaces et pas uniquement sur localhost :
ss -tlnup | grep -E '2111[5-7]'
SI la colonne Local Address affiche 127.0.0.1:2111x au lieu de 0.0.0.0:2111x :
cat /etc/systemd/system/hbbs.service | grep ExecStart
Vérifier que l'argument -r ne force pas une écoute locale. Corriger et redémarrer :
systemctl daemon-reload && systemctl restart hbbs hbbr
7.2 Mauvaise IP encore configurée dans les services
grep -r '10.192.193.110' /etc/systemd/system/hbbs.service
grep -r '10.192.193.110' /etc/systemd/system/hbbr.service
SI l'ancienne IP est trouvée :
sed -i 's/10\.192\.193\.110/10.192.194.110/g' /etc/systemd/system/hbbs.service
sed -i 's/10\.192\.193\.110/10.192.194.110/g' /etc/systemd/system/hbbr.service
systemctl daemon-reload
systemctl restart hbbs hbbr
7.3 Ports bloqués par le pare-feu OPNsense
Depuis un client, tester chaque port individuellement :
Test-NetConnection -ComputerName 10.192.194.110 -Port 21115
Test-NetConnection -ComputerName 10.192.194.110 -Port 21116
Test-NetConnection -ComputerName 10.192.194.110 -Port 21117
SI TcpTestSucceeded : False sur un port :
1. Aller dans Firewall > Log Files > Live View sur OPNsense
2. Filtrer sur 10.192.194.110 et le port concerné
3. SI le flux apparaît avec action "block" : la règle est manquante ou mal configurée
4. Vérifier l'interface source dans la règle (correspond au VLAN du client)
5. Vérifier que "Apply changes" a bien été cliqué après modification
7.4 Problème de clé publique côté client
Symptôme : le client se connecte au serveur (statut vert) mais la connexion à distance échoue avec une erreur d'authentification ou de clé.
Vérifier la clé présente dans la config client :
Fichier : RustDesk2.toml
Ligne : key = 'XXXXXXXXXX'
Comparer avec la clé réelle du serveur :
cat /opt/rustdesk-server/id_ed25519.pub
SI les clés ne correspondent pas : mettre à jour le champ key dans RustDesk2.toml sur les clients concernés avec la valeur exacte retournée par la commande ci-dessus.
7.5 Problème de routage inter-VLAN
Depuis le serveur RustDesk (VLAN DMZ), vérifier si un client du VLAN source est joignable :
ping -c 4 10.192.193.50
SI non joignable : le routage inter-VLAN n'est pas configuré ou est bloqué côté OPNsense.
Vérifier dans OPNsense :
Firewall > Rules > VLAN_DMZ
Une règle de retour autorisant les flux établis (state: established) doit exister, ou une règle explicite autorisant la DMZ à répondre vers les clients.
7.6 Ancienne IP encore résolue par les clients
SI des clients utilisent un nom DNS à la place de l'IP pour joindre le serveur RustDesk :
nslookup rustdesk.mpr-if.infra
SI l'ancienne IP 10.192.193.110 est retournée : mettre à jour l'enregistrement DNS A du serveur RustDesk vers 10.192.194.110 et vider le cache DNS client :
ipconfig /flushdns
systemd-resolve --flush-caches
7.7 Réseau non redémarré correctement après modification
SI après systemctl restart networking l'interface ne prend pas la nouvelle IP :
ip a
SI l'ancienne IP est encore présente :
ip addr flush dev ens18
ifdown ens18 && ifup ens18
SI toujours en échec, appliquer manuellement :
ip addr add 10.192.194.110/24 dev ens18
ip route add default via 10.192.194.1
ip addr del 10.192.193.110/24 dev ens18
Puis vérifier et corriger /etc/network/interfaces pour la persistance.
7.8 Collecte de diagnostic complet en cas de blocage
systemctl status hbbs hbbr --no-pager > /tmp/diag-rustdesk.txt
ss -tlnup >> /tmp/diag-rustdesk.txt
ip a >> /tmp/diag-rustdesk.txt
ip route >> /tmp/diag-rustdesk.txt
journalctl -u hbbs -n 50 --no-pager >> /tmp/diag-rustdesk.txt
journalctl -u hbbr -n 50 --no-pager >> /tmp/diag-rustdesk.txt
cat /etc/systemd/system/hbbs.service >> /tmp/diag-rustdesk.txt
cat /etc/systemd/system/hbbr.service >> /tmp/diag-rustdesk.txt
cat /tmp/diag-rustdesk.txt