Table of Contents

Quand ce n’est pas le réseau : une enquête RDP qui a mené ailleurs

Auteur(s) : Louis Ouellet

Dans le cadre d’un déploiement récent, on m’a demandé d’enquêter sur des sessions Remote Desktop (RDP) instables vers un serveur distant accessible via un VPN site-à-site.

Au départ, l’explication semblait simple : le VPN était instable. Les utilisateurs étaient déconnectés, le serveur était distant, et tous les symptômes semblaient pointer dans la même direction.

Sur papier, l’environnement était pourtant simple :

Mais comme c’est souvent le cas en infrastructure, la première explication était surtout la plus pratique — pas la plus exacte.

C’est typiquement le genre de situation où tout ressemble à un problème réseau… jusqu’à ce que l’on prouve ce qui fonctionne réellement — et ce qui ne fonctionne pas.

Contexte

Le problème n’a pas commencé avec WireGuard.

À l’origine, la connectivité reposait sur un tunnel IPsec. Lorsque celui-ci a cessé de fonctionner, la première réaction a été de dire que le tunnel apparaissait toujours actif du côté distant — donc que le problème venait forcément de mon côté.

De mon côté, les faits racontaient une autre histoire. Des captures de paquets sur l’interface WAN montraient clairement que mon pare-feu envoyait du trafic, sans recevoir de réponses. Un traceroute est allé encore plus loin : le point de terminaison IPsec distant n’était même plus joignable.

En parallèle, les utilisateurs signalaient déjà des problèmes de performance en se connectant à 192.168.201.100. Ces plaintes existaient avant la panne IPsec, ce qui compliquait la situation. Il y avait maintenant un tunnel brisé, mais aussi un problème de performance plus ancien sur le même serveur distant.

Même avant d’aller plus loin dans l’analyse, certains signaux laissaient entrevoir un problème potentiel de capacité. Lors d’échanges avec l’équipe distante, il a été mentionné que l’utilisation CPU et mémoire tournait généralement autour de 80 % en conditions normales. D’après mon expérience avec les environnements RDS et VDI, cela laisse très peu de marge pour absorber les pics d’activité.

Cela ne prouvait rien en soi, mais rendait l’hypothèse d’une saturation des ressources crédible et digne d’être validée.

Avant même la panne complète du tunnel IPsec, j’avais déjà partagé quelques recommandations pour réduire la charge côté serveur, comme publier l’application en RemoteApp ou diminuer la charge graphique. Ces suggestions n’ont pas donné suite, notamment parce que l’expérience semblait différente pour d’autres utilisateurs.

Une fois le tunnel IPsec inutilisable, la solution proposée a été de passer à WireGuard.

Il a été suggéré de déployer WireGuard directement sur le serveur RDS, mais ce n’était pas une approche que j’étais prêt à adopter. Faire terminer un VPN directement sur un serveur de production introduit des problèmes de sécurité et d’architecture réseau inutiles. Comme une mise à jour de pfSense aurait nécessité une interruption de service, j’ai plutôt mis en place une machine virtuelle Ubuntu Server 24.04 LTS dédiée comme passerelle WireGuard, avec le routage approprié sur pfSense.

C’est à ce moment que la véritable investigation a commencé.

Le problème

Une fois le tunnel WireGuard en place, les utilisateurs ont pu se reconnecter, mais le problème principal persistait.

Ils rapportaient :

Cela créait une situation classique et trompeuse :

Le ping est stable, mais l’application ne l’est pas.

C’est exactement le type de symptôme qui peut orienter une investigation dans la mauvaise direction si l’on s’arrête à la première hypothèse.

Investigation

Plutôt que de considérer le VPN comme coupable par défaut, j’ai abordé le problème couche par couche.

1. Validation de la stabilité réseau

La première étape consistait à vérifier si le chemin lui-même était instable.

Tests ICMP et validation du MTU : 

ping 192.168.201.100 -f -l 1300

Après plusieurs tests :

Résultats :

Conclusion : le chemin réseau est suffisamment stable pour transporter le trafic.

2. Validation du tunnel WireGuard

Vérification du tunnel : 

wg show
conntrack -L
iptables -L

Observations :

Conclusion : le tunnel WireGuard fonctionne correctement.

3. Analyse du transport RDP

Analyse avec tcpdump :

Exemple : 

IP 192.168.201.20.51020 > 192.168.201.100.3389: UDP, length 1237
IP 192.168.201.20.51020 > 192.168.201.100.3389: UDP, length 1005

Cela ressemblait encore à un problème réseau — mais les preuves ne montraient aucune perte de paquets.

4. Corrélation avec les performances serveur

Changement d’approche : corrélation avec les métriques système. 

typeperf "\Processor(_Total)\% Processor Time" "\Memory\% Committed Bytes In Use"

Résultat :

C’est ici que l’investigation a pris un tournant.

Avec le recul, les données de performance confirmaient les observations initiales : le serveur n’avait pratiquement aucune marge lorsque l’activité utilisateur augmentait.

À ce stade, la question n’était plus de savoir si les paquets passaient — ils passaient — mais si le serveur pouvait suivre la charge.

Cause racine

Le problème n’était pas le VPN, mais une saturation des ressources serveur, principalement CPU.

Lorsqu’un serveur RDP atteint 100% CPU :

Un problème de calcul qui se manifeste comme un problème réseau.

Hypothèses trompeuses

Toutes plausibles, mais incorrectes.

Un ping stable ne garantit pas une application stable.

Solutions recommandées

1. Augmenter les ressources

2. Réduire la charge graphique

Mise en perspective

Le diagnostic pointait clairement vers un problème de ressources serveur.

Solutions possibles :

Solution retenue :

Ajouter des tunnels ne résout pas un problème de capacité serveur.

À retenir

Conclusion

Ce cas rappelle que les problèmes d’infrastructure sont souvent guidés par des hypothèses autant que par la technique.

Ce qui semblait être un problème VPN était en réalité une limitation de ressources serveur.

Même si la solution finale n’est pas toujours celle que l’on aurait choisie, une investigation rigoureuse reste toujours utile.

Articles connexes

Tags

, , , , ,