Gel de RDP via VPN : l’entrée fonctionne encore, testez donc le transport

Quand l’image cesse de se rafraîchir mais que la souris glisse encore sur le bureau distant, la conclusion évidente est que le VPN a sauté. Cette conclusion est généralement fausse. Une image figée avec une entrée fonctionnelle signifie que la session et son canal d’entrée sont vivants, ce qui pousse la panne vers le transport graphique plutôt que vers le routage ou les identifiants. Deux observations rapides séparent les trois pannes que les utilisateurs décrivent avec le même mot.

Ce que le gel ne vous dit pas

Le Bureau à distance transporte l’entrée et les mises à jour d’écran via TCP 3389, et les clients Windows actuels peuvent ajouter un transport UDP pour la partie du flux la plus lourde en graphismes. Sur un tunnel qui fragmente ou abandonne les datagrammes plus gros, le canal fiable continue de transporter les frappes tandis que le canal graphique se bloque. Le résultat est l’étrange combinaison d’une image figée et d’un clavier qui répond. Cela explique aussi pourquoi se reconnecter guérit parfois le symptôme pendant une minute avant de le ramener.

Une session qui se déconnecte et se reconnecte est une autre panne, et une session qui ne s’ouvre jamais en est une troisième. Nommer d’abord la forme vous évite de tester la mauvaise couche.

Séparez les trois pannes avec deux commandes

Écarter l’accessibilité coûte peu. Testez le port RDP depuis le client, puis lisez l’état de la session sur l’hôte.

Test-NetConnection rdp-host.example.com -Port 3389
query user /server:rdp-host

Un test TCP échoué signifie que la session ne s’est jamais ouverte : traitez-le donc comme un problème de pare-feu, de portée ou de service, et non comme un gel. Un test réussi avec une session active confirme que le canal de contrôle existe, ce qui est exactement le cas de l’image figée. Lancez l’interrogation de l’hôte depuis un compte autorisé à voir les sessions, car une erreur de permission ressemble à une liste vide. Notez l’ID et l’état de la session, car une session déconnectée qui conserve son ID n’est pas identique à une session active.

Désactivez le transport UDP et comparez

Si seul l’affichage se bloque, comparez les transports client en ne changeant qu’une chose à la fois. Le client intégré et le client du Store ne partagent pas la même pile, et la politique ci-dessous retire UDP du client intégré.

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP

Une valeur de 1 signifie qu’UDP est déjà désactivé pour ce client : un gel qui survit à ce réglage n’est donc pas un problème de chemin UDP. Quand la valeur est absente, activez la politique, reconnectez-vous et répétez exactement l’action qui avait gelé. Testez le client du Store comme une étape distincte au lieu de combiner les deux changements, sinon vous ne saurez pas lequel comptait. Gardez la version du client dans vos notes, car le comportement du transport a évolué au fil des versions de Windows.

Quand un seul hôte gèle mais que les autres vont bien

Un seul hôte défaillant sur un sous-réseau par ailleurs sain pointe ailleurs que vers le tunnel. Vérifiez le MTU du chemin et la pile d’affichage distant avant de toucher aux réglages VPN.

ping -f -l 1472 rdp-host.example.com

Une réponse prouve que le chemin transporte un paquet de taille pleine sans fragmentation à cette taille, tandis qu’un échec avec l’indicateur de non-fragmentation suggère que le MTU du tunnel demande attention. Si 1472 octets passent et que seul cet hôte gèle, regardez son pilote graphique et sa charge plutôt que le réseau. Une copie de fichier rapide vers la même machine dit quelque chose du débit, pas du canal graphique RDP. Changez une variable à la fois et répétez la même action à l’écran pour que la comparaison ait un sens.

Si la session ne s’ouvre jamais, arrêtez-vous ici, car c’est de l’accessibilité et non un gel. Sinon, conservez le réglage de transport qui a changé le symptôme et notez-le avec la version du client.