Bureau à distance impossible sur un VPS Windows Server : dépannage RDP

Quand le Bureau à distance ne parvient pas à se connecter à votre VPS Windows Server, la cause se trouve presque toujours parmi cinq points : le chemin réseau vers le port 3389, RDP désactivé, le pare-feu Windows, une incompatibilité d'authentification NLA/CredSSP ou un compte verrouillé. Ce guide de dépannage RDP les vérifie un par un. Il s'applique à Windows Server 2016, 2019 et 2022 sur tout serveur cloud JUSTG, qu'il soit hébergé à Johannesburg, Moscou, Tokyo ou Séoul. Les exemples utilisent l'IP 203.0.113.10 : remplacez-la par la vôtre.

Étape 1 : Tester le port RDP 3389 depuis votre ordinateur

On commence par l'extérieur. Si le test TCP échoue, le problème vient du chemin réseau ou le serveur n'écoute pas ; s'il réussit mais que la connexion est refusée, passez à l'étape 4.

# On your own Windows PC (PowerShell)
Test-NetConnection -ComputerName 203.0.113.10 -Port 3389

# On macOS / Linux
nc -vz 203.0.113.10 3389

TcpTestSucceeded : True signifie que le port est joignable. Si la valeur est False, vérifiez dans l'espace client que le VPS est démarré et qu'il répond au ping. Contrôlez aussi votre propre réseau : certains pare-feu d'entreprise bloquent le 3389 sortant, essayez donc depuis un partage de connexion mobile.

Étape 2 : Vérifier que le Bureau à distance est activé et à l'écoute

Ouvrez la console VNC, connectez-vous puis lancez PowerShell en tant qu'administrateur. Contrôlez l'état du service Remote Desktop Services (TermService), la valeur fDenyTSConnections (0 = RDP autorisé, 1 = bloqué) et le port réellement utilisé :

Get-Service -Name TermService
Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections
Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber
Get-NetTCPConnection -LocalPort 3389 -State Listen

Si le port RDP a été modifié auparavant, PortNumber l'indique et il faut se connecter avec IP:port. Si RDP est désactivé ou le service arrêté, réactivez-les :

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0
Set-Service -Name TermService -StartupType Automatic
Start-Service -Name TermService

Étape 3 : Corriger la règle du pare-feu Windows pour le Bureau à distance

Un script de durcissement ou un nettoyage manuel désactive souvent les règles intégrées du Bureau à distance. Sur une édition française, le nom du groupe est traduit ; utilisez donc l'identifiant de groupe basé sur la ressource, valable dans toutes les langues :

# Language-independent group name for the built-in Remote Desktop rules
Enable-NetFirewallRule -Group "@FirewallAPI.dll,-28752"
Get-NetFirewallRule -Group "@FirewallAPI.dll,-28752" | Select-Object DisplayName, Enabled, Profile

# If the built-in rules were deleted, create one manually
New-NetFirewallRule -DisplayName "Allow RDP 3389" -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Allow

Si vous avez changé le port RDP, ouvrez ce port à la place du 3389. Relancez l'étape 1 : le test TCP doit maintenant réussir.

Étape 4 : Résoudre les erreurs d'authentification NLA et CredSSP

Si le port est ouvert mais que le client affiche « Une erreur d'authentification s'est produite… correction de l'oracle de chiffrement CredSSP » ou un message lié à NLA, le client et le serveur n'ont pas le même niveau de mises à jour. La vraie solution consiste à installer Windows Update sur le serveur via la console VNC, ainsi que sur votre PC. En dépannage temporaire, désactivez l'authentification au niveau du réseau (NLA) sur le serveur, connectez-vous, faites les mises à jour puis réactivez-la :

# Temporary: turn off Network Level Authentication (run in the VNC console)
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 0

# Turn it back on after the server is fully updated
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 1

Étape 5 : Compte verrouillé et « trop de sessions »

Un RDP exposé sur Internet attire les robots qui testent des mots de passe, et une stratégie de verrouillage peut bloquer votre compte. Dans la console VNC, consultez la stratégie, l'état du compte et les sessions actives. Windows Server autorise par défaut deux sessions d'administration ; fermez une session orpheline grâce à son ID :

net accounts
net user Administrator
qwinsta
logoff 2

Si un compte local est verrouillé, ouvrez lusrmgr.msc, affichez les propriétés de l'utilisateur et décochez Le compte est verrouillé, ou attendez la durée de verrouillage indiquée par net accounts. Pour réduire les attaques par force brute, déplacez RDP sur un port non standard et limitez la règle de pare-feu à vos propres adresses IP.

Questions fréquentes

Le ping répond mais le Bureau à distance ne se connecte toujours pas. Pourquoi ?

Le ping prouve seulement que l'ICMP passe. RDP exige que le port TCP 3389 (ou votre port personnalisé) soit à l'écoute et autorisé par le pare-feu. Suivez les étapes 2 et 3 depuis la console VNC.

RDP fonctionnait hier et ne marche plus après un redémarrage de Windows Update.

Patientez quelques minutes après le redémarrage : une grosse mise à jour peut rester longtemps sur l'écran « Travail sur les mises à jour », visible dans la console VNC. Si une erreur CredSSP apparaît ensuite, mettez aussi votre PC à jour.

Puis-je me connecter à mon VPS Windows JUSTG en IPv6 ?

Oui. Tous les serveurs cloud JUSTG incluent l'IPv6 gratuitement. Une fois l'adresse configurée sur le serveur, saisissez-la entre crochets dans le client Bureau à distance, par exemple [2001:db8::10].

Si le Bureau à distance refuse toujours de se connecter après ces vérifications, ouvrez un ticket auprès du support technique JUSTG en joignant le résultat des étapes 1 et 2 ; nous vous aiderons à poursuivre l'analyse.