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 :

• Réseau local : 192.168.115.0/24
• Réseau distant : 192.168.201.0/24
• VPN initial : IPsec
• VPN temporaire : WireGuard
• Serveur cible : 192.168.201.100
• Plusieurs utilisateurs connectés en RDP

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

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é.

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

Ils rapportaient :

• Des déconnexions RDP aléatoires
• Une instabilité notable lors de l’utilisation active
• Des reconnexions partielles (lecteurs et imprimantes redirigés revenant progressivement)
• Aucune perte de paquets évidente lors de tests de connectivité de base

Cela créait une situation classique et trompeuse :

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.

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

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 :

• MTU optimal : 1380 bytes

Résultats :

• Aucune perte de paquets
• Latence stable

Vérification du tunnel :

wg show
conntrack -L
iptables -L

Observations :

• Handshakes réguliers et stables
• Aucune saturation conntrack
• Aucun blocage firewall
• Trafic bidirectionnel fonctionnel

Analyse avec tcpdump :

• Utilisation importante de l’UDP
• Trafic en rafales lors des interactions
• Paquets entre ~1000 et 1200 bytes
• Fallback TCP instable

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

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

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

Résultat :

• CPU atteignant 100% au moment exact des déconnexions

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.

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

Lorsqu’un serveur RDP atteint 100% CPU :

• Traitement des sessions ralenti
• Retard d’affichage
• Dégradation du transport
• Comportement similaire à une perte réseau

• VPN instable
• MTU / fragmentation
• UDP vs TCP
• Firewall / conntrack

Toutes plausibles, mais incorrectes.

• Ajouter du CPU
• Augmenter la RAM
• Surveiller la charge

• Utiliser RemoteApp
• Réduire résolution / écrans
• Désactiver effets visuels

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

Solutions possibles :

• Augmenter les ressources
• Réduire la charge

Solution retenue :

• Ajouter des postes clients
• Multiplier les tunnels

• Ne pas blâmer le réseau par défaut
• Valider chaque couche
• VPN ≠ application stable
• Saturation serveur peut imiter un problème réseau
• La solution doit correspondre à la cause

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.