VPN d’entreprise + RDP : Bureau à distance sécurisé sans exposer RDP sur Internet

novembre 24, 2025 • février 3, 2026 • Lecture : 28 min • Views: 10

Cet article vous a aidé ?

L’entreprise veut « juste RDP » parce que c’est familier, rapide et compatible avec tous les vieux trucs Windows qui refusent de mourir.
La sécurité veut « pas de ports publics » parce qu’elle a vu ce que l’Internet fait à un 3389 exposé. Vous êtes coincé au milieu, avec le pager.

La bonne nouvelle : vous pouvez avoir un bureau à distance qui ressemble à RDP, sans jamais laisser RDP toucher Internet public.
La mauvaise nouvelle : vous devez être discipliné sur les frontières réseau, l’identité et le diagnostic — car quand ça casse, ça casse à 2 h du matin.

L’objectif : RDP reste privé

La règle de base est embarrassante de simplicité : RDP ne doit jamais être accessible depuis l’internet public.
Pas « c’est ok si on limite le débit ». Pas « c’est ok si on change le port ». Pas « c’est ok parce qu’on est petit ».
Il doit être inaccessible depuis l’extérieur. Point final.

À la place, les utilisateurs établissent un tunnel sécurisé vers le réseau de bureau — typiquement un VPN — puis initient RDP vers des hôtes internes.
Cela vous donne un point d’étranglement pour l’authentification, la MFA, le contrôle des appareils et la journalisation. Cela vous donne aussi un endroit unique où les choses peuvent casser,
ce qui est… honnêtement mieux que de casser partout.

Si vous êtes tenté de publier le 3389 avec une règle de pare-feu « temporaire », souvenez-vous : les règles temporaires ont la durée de vie des restes sans étiquette dans le frigo du bureau.

Faits et contexte historique (ce qui explique le bazar actuel)

RDP existe depuis la fin des années 1990, issu de l’époque des Terminal Services de Microsoft ; il a été conçu pour des réseaux gérés, pas pour les bords hostiles d’Internet.
Le port TCP/3389 est devenu une cible de scans dès que le balayage massif d’Internet est devenu bon marché ; changer de port n’a jamais vraiment résolu ça.
Network Level Authentication (NLA) a été introduit pour déplacer l’authentification en amont dans le flux de connexion, réduisant l’abus de ressources et une partie de la surface d’attaque.
BlueKeep (CVE-2019-0708) a rappelé à tous que les bugs RDP pré-authentification peuvent être wormables ; ce n’était pas le premier, ni le dernier.
Les groupes de rançongiciel ont industrialisé le brute force sur RDP car c’est direct et rentable : un identifiant = un poste = mouvements latéraux.
Les VPN sont passés de « plomberie site-à-site » à « porte d’entrée d’identité » avec la montée du télétravail ; beaucoup d’organisations les traitent encore comme des simples tunnels.
Le split tunneling s’est popularisé pour réduire les coûts de bande passante et éviter le hairpinning, mais il est aussi apprécié par les répondeurs d’incident qui aiment la douleur.
RD Gateway existe parce que le RDP brut est pénible à grande échelle : il offre une politique centrale et le transport HTTPS, mais reste un service publié à protéger.
L’accès distant moderne converge vers le Zero Trust : posture de l’appareil + accès par application ; VPN+RDP peut s’en approcher si vous êtes strict.

Architecture de référence : VPN d’abord, RDP ensuite

Voici l’architecture qui tend à survivre aux audits et aux vrais attaquants :

Point d’entrée VPN sur une passerelle durcie (ou une paire, si vous aimez dormir), exposé sur un seul port (par ex. UDP/51820 pour WireGuard).
Authentification forte : certificats/clefs plus MFA (ou un VPN qui s’intègre à un IdP). Si vous ne pouvez pas faire de MFA, vous n’avez pas fini.
RDP réservé au réseau interne : RDP écoute uniquement sur les interfaces LAN/VPN ; les règles de pare-feu limitent les sources aux sous-réseaux VPN et seulement aux jump hosts autorisés.
Segmentation : les utilisateurs n’atteignent que les hôtes dont ils ont besoin. « Les utilisateurs VPN peuvent accéder à tout un /16 » est la façon d’entraîner un rançongiciel à sprinter.
Journalisation : connexions/déconnexions VPN, connexions RDP et actions d’admin centralisées. Si vous ne pouvez pas répondre à « qui a accédé à l’hôte X à l’heure Y », vous devinez.
Jump box / bastion optionnel : une ou une petite flotte de jump hosts Windows durcis. Les utilisateurs RDP vers le jump host, puis vers les cibles internes.

Pourquoi un jump host est souvent le choix adulte

Les jump hosts semblent old-school, mais ils imposent une frontière claire : le VPN vous amène au jump host, et le jump host vous amène à tout le reste.
Cela signifie moins de machines avec RDP activé, moins de machines dans le groupe « Remote Desktop Users » et moins de machines à gérer pour les bizarreries du client RDP.

Ils centralisent aussi la journalisation. Windows peut journaliser l’activité RDP par hôte, certes, mais concentrer l’accès via un petit ensemble d’hôtes rend votre chronologie d’incident
moins comme une chasse au trésor et plus comme une enquête.

Décisions difficiles : VPN vs RD Gateway vs les deux

VPN + RDP interne (le focus ici)

Idéal si vous contrôlez les postes clients, pouvez déployer la config VPN proprement et voulez que RDP reste interne.
C’est l’approche « ne pas exposer RDP à l’internet » dans sa forme la plus pure : le seul composant face au public est le point d’accès VPN.

RD Gateway (RDP sur HTTPS)

RD Gateway encapsule RDP dans HTTPS (TCP/443), ce qui est pratique dans des réseaux restrictifs.
Il centralise l’autorisation et peut réduire le besoin d’un accès réseau complet. Mais c’est un service public : il faut le patcher, le surveiller
et le défendre comme tout autre système exposé à Internet.

Les deux (oui, parfois)

Certaines organisations placent RD Gateway derrière un VPN quand même. Ça paraît redondant jusqu’à ce que vous gériez :
(1) des contractuels qui ne doivent accéder qu’à un sous-ensemble de postes,
(2) le besoin de contrôles d’accès conditionnels à plusieurs couches,
(3) des régimes de conformité qui aiment la défense en profondeur quand elle est bien configurée.

Avis subjectif : si vous êtes une petite ou moyenne organisation et que vous pouvez déployer des clients VPN de façon fiable, VPN + jump hosts offre le meilleur ratio coût/sécurité.
Si vous avez beaucoup d’appareils non gérés, considérez RD Gateway avec un durcissement sérieux — ou mieux, un modèle d’accès par application qui évite l’accès réseau large.

Construction : VPN d’entreprise WireGuard (pratique, rapide, ennuyeux)

WireGuard n’est pas magique. Il est toutefois étonnamment petit, rapide et facile à comprendre comparé aux piles VPN plus anciennes.
Si vous exploitez des systèmes de production, « facile à raisonner » est une fonctionnalité que vous pouvez justifier dans un tableau budgétaire.

Plan réseau (n’improvisez pas en prod)

Sous-réseau VPN : 10.44.0.0/24 (les clients y vivent)
LAN de bureau : 10.10.0.0/16 (serveurs/postes de travail)
Serveur WireGuard : 10.44.0.1
Jump hosts : 10.10.20.10–10.10.20.20

Bases du durcissement du serveur

Placez le point d’accès VPN sur une VM ou un appliance dédié, pas sur le serveur de fichiers, pas sur le contrôleur de domaine, et certainement pas sur « cette machine sous le bureau de quelqu’un ».
Gardez l’OS minimal. Patchez-le. Restreignez les ports entrants au port VPN et au SSH depuis des plages admin de confiance uniquement.

Verrouiller RDP sous Windows (pour qu’il se comporte)

Activer RDP est facile. L’activer de façon sûre est là où les gens commencent à négocier.
Vous voulez : NLA activé, TLS moderne, délais raisonnables, membres de groupes limités et portée du pare-feu limitée au sous-réseau VPN (et éventuellement au sous-réseau des jump hosts).

Aussi : désactivez les comptes administrateurs « au cas où ». Utilisez des identités admin séparées. Journalisez. Si vous ne pouvez pas journaliser, vous ne pouvez pas défendre.

Pare-feu et segmentation (où la plupart des équipes échouent)

Le VPN n’est pas une cape magique de sécurité. C’est un événement de routage. Si les clients VPN peuvent router vers tout,
alors un portable compromis peut router vers tout aussi. Vos règles de pare-feu doivent refléter le travail, pas la topologie réseau héritée.

Attitude minimale de pare-feu

Les clients VPN peuvent atteindre seulement les jump hosts sur TCP/3389.
Les administrateurs peuvent atteindre les ports de gestion (WinRM, SSH, etc.) depuis des sous-réseaux admin dédiés.
Bloquez le RDP est-ouest sauf si c’est explicitement nécessaire.
Journalisez les refus depuis le sous-réseau VPN. Pas pour toujours, mais assez longtemps pour enquêter.

Split tunneling : choisissez avec soin

Le split tunneling signifie qu’une partie du trafic passe par le VPN ; le reste va directement sur Internet.
C’est bon pour la bande passante et terrible pour les hypothèses. Si votre modèle de sécurité repose sur « VPN = réseau de confiance », le split tunneling le casse.

Si vous devez utiliser le split tunneling, traitez les clients VPN comme semi-hostiles : restreignez ce qu’ils peuvent atteindre, exigez la MFA et journalisez agressivement.

Identité : MFA, posture des appareils et le mythe du « VPN de confiance »

L’accès VPN n’est pas l’identité. C’est la connectivité. L’identité, c’est : qui est cet utilisateur, depuis quel appareil, avec quel niveau d’assurance, et mérite-t-il encore l’accès maintenant ?

Si votre VPN supporte le SSO et l’accès conditionnel, utilisez-les. S’il ne le fait pas, compensez : identifiants à courte durée, clefs par utilisateur et une barrière MFA séparée.
Pour RDP lui-même, n’autorisez pas les comptes locaux quand vous pouvez les éviter. Liezn-le aux identités annuaire et contrôlez l’appartenance à « Remote Desktop Users ».

Une idée paraphrasée de Werner Vogels (CTO d’Amazon) : « Tout échoue, tout le temps. » Constr uisez l’accès distant comme si l’échec était l’état par défaut.
Parce que c’est le cas.

Journalisation et supervision : prouver qui a fait quoi

Vous avez besoin de deux chronologies : chronologie VPN (qui s’est connecté, d’où, avec quel appareil) et chronologie Windows (qui s’est connecté, où, et quel type de session).
Mettez-les au même endroit. Corrélez par nom d’utilisateur, IP source (IP VPN) et heure.

Sur Windows, intéressez-vous aux événements de connexion (interactive vs remote interactive), aux connexions échouées, aux verrouillages de compte et aux changements d’appartenance aux groupes.
Sur la passerelle VPN, surveillez les handshakes réussis, les changements de configuration et les anomalies de trafic.

Tâches pratiques : 12+ commandes, sorties et décisions

Voici les tâches que j’exécute réellement quand je monte ou débogue VPN+RDP en production. Chaque tâche inclut : une commande, ce que signifie la sortie et la décision suivante.
Les commandes sont montrées depuis une passerelle VPN Linux sauf indication contraire. Pour les vérifications Windows, j’utilise PowerShell sur un hôte Windows quand nécessaire, mais invoqué en bash via SSH ou un shell de gestion.

Task 1: Confirm WireGuard interface and peer handshakes

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 6xk2n3m...redacted
  listening port: 51820

peer: uRk9hQ...redacted
  endpoint: 198.51.100.24:53312
  allowed ips: 10.44.0.10/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 148.32 MiB received, 210.77 MiB sent
  persistent keepalive: every 25 seconds

Signification : « latest handshake » vous dit que le tunnel est vivant ; les compteurs de transfert indiquent que du trafic circule.
Décision : Si le handshake est « never » ou ancien, arrêtez de blâmer RDP. Réparez d’abord la connectivité VPN, les clefs, le NAT ou le pare-feu.

Task 2: Verify the server is actually listening on the VPN port

cr0x@server:~$ sudo ss -lunpt | grep 51820
udp   UNCONN 0      0            0.0.0.0:51820      0.0.0.0:*    users:(("wg-quick",pid=1123,fd=6))

Signification : UDP 51820 est lié sur toutes les interfaces.
Décision : Si rien n’écoute, votre service WireGuard n’est pas lancé, ou il est lié de manière incorrecte. Réparez le service et la config avant toute autre chose.

Task 3: Confirm IP forwarding on the VPN gateway (Linux)

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Signification : La passerelle peut router les paquets entre interfaces.
Décision : Si c’est 0, les clients VPN peuvent se connecter mais n’atteindront pas les hôtes du LAN. Activez le forwarding et persistez la config.

Task 4: Check route table for VPN subnet and LAN path

cr0x@server:~$ ip route
default via 203.0.113.1 dev eth0
10.10.0.0/16 via 10.10.0.1 dev eth1
10.44.0.0/24 dev wg0 proto kernel scope link src 10.44.0.1

Signification : La passerelle sait où se trouve le LAN et que wg0 possède le sous-réseau VPN.
Décision : Si la route LAN manque ou est incorrecte, le trafic client VPN sera perdu. Corrigez le routage avant de toucher à Windows.

Task 5: Verify firewall allows inbound WireGuard and blocks public RDP

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 ip saddr 203.0.113.50 accept
    udp dport 51820 accept
    tcp dport 3389 drop
  }
}

Signification : Le VPN est autorisé ; le RDP sur la passerelle elle-même est explicitement rejeté (bonne pratique supplémentaire).
Décision : Si vous voyez une règle accept pour tcp/3389 sur une interface publique, retirez-la. Ne négociez pas avec les incidents futurs.

Task 6: Test reachability from gateway to a Windows jump host on 3389

cr0x@server:~$ nc -vz 10.10.20.10 3389
Connection to 10.10.20.10 3389 port [tcp/ms-wbt-server] succeeded!

Signification : Le jump host est joignable et le port RDP est ouvert du point de vue réseau de la passerelle.
Décision : Si ça échoue, vous avez probablement un pare-feu Windows, des ACL réseau ou des problèmes de routage entre la passerelle et le sous-réseau des jump hosts.

Task 7: Test reachability from a VPN client IP to jump host (simulate from gateway)

cr0x@server:~$ sudo nft add rule inet filter forward ip saddr 10.44.0.0/24 ip daddr 10.10.20.10 tcp dport 3389 counter accept
cr0x@server:~$ sudo nft list chain inet filter forward
table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ip saddr 10.44.0.0/24 ip daddr 10.10.20.10 tcp dport 3389 counter packets 0 bytes 0 accept
  }
}

Signification : Vous avez créé une règle explicite d’autorisation pour les clients VPN vers le RDP du jump host, avec compteurs.
Décision : Utilisez les compteurs pour confirmer que le trafic atteint la règle. Si les compteurs restent à 0 pendant une tentative de connexion, le trafic n’atteint pas cette machine (routage/NAT/config client).

Task 8: Confirm Windows has RDP enabled and NLA required (PowerShell on jump host)

cr0x@server:~$ ssh admin@10.10.20.10 'powershell -NoProfile -Command "Get-ItemProperty -Path \"HKLM:\System\CurrentControlSet\Control\Terminal Server\" -Name fDenyTSConnections; Get-ItemProperty -Path \"HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\" -Name UserAuthentication"'
fDenyTSConnections : 0
PSPath              : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server
PSParentPath        : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control
PSChildName         : Terminal Server
PSDrive             : HKLM
PSProvider          : Microsoft.PowerShell.Core\Registry

UserAuthentication : 1
PSPath             : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
PSParentPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations
PSChildName        : RDP-Tcp
PSDrive            : HKLM
PSProvider         : Microsoft.PowerShell.Core\Registry

Signification : fDenyTSConnections=0 signifie RDP activé ; UserAuthentication=1 signifie NLA requis.
Décision : Si NLA est désactivé, activez-le sauf si vous avez une raison documentée (et un plan) pour fonctionner sans.

Task 9: Check Windows Firewall rule scope for RDP (avoid “Any”)

cr0x@server:~$ ssh admin@10.10.20.10 'powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup \"Remote Desktop\" | Get-NetFirewallAddressFilter | Select-Object Name,RemoteAddress | Format-Table -AutoSize"'
Name                                   RemoteAddress
----                                   -------------
RemoteDesktop-UserMode-In-TCP           Any
RemoteDesktop-UserMode-In-UDP           Any
RemoteDesktop-Shadow-In-TCP             Any

Signification : « Any » comme adresse distante signifie que quiconque peut router vers cet hôte peut tenter RDP.
Décision : Changez la portée pour le sous-réseau VPN (10.44.0.0/24) et/ou le sous-réseau des jump hosts uniquement. « Any » va pour un labo ; c’est paresseux en prod.

Task 10: Validate that RDP is not exposed publicly (external scan from the gateway’s public side)

cr0x@server:~$ nmap -Pn -p 3389 203.0.113.10
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-28 15:42 UTC
Nmap scan report for 203.0.113.10
Host is up (0.012s latency).

PORT     STATE  SERVICE
3389/tcp closed ms-wbt-server

Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds

Signification : Fermé est bien ici. « Filtré » est aussi acceptable (souvent préférable), selon la politique.
Décision : Si c’est ouvert, stoppez. Corrigez le pare-feu/NAT périmétrique immédiatement. Ne procédez pas tant que 3389 est joignable depuis Internet.

Task 11: Check DNS behavior for VPN clients (the sneaky cause of “RDP is down”)

cr0x@server:~$ dig +short jump01.corp.example A @10.10.0.53
10.10.20.10

Signification : Le DNS interne résout le jump host vers une IP interne.
Décision : Si les clients VPN utilisent un DNS public, ils peuvent résoudre vers un enregistrement public ou rien du tout. Corrigez le push DNS VPN ou la politique de résolveur client.

Task 12: Confirm client can route to LAN via VPN (from VPN gateway, inspect conntrack)

cr0x@server:~$ sudo conntrack -L | grep 10.44.0.10 | head
tcp      6 431999 ESTABLISHED src=10.44.0.10 dst=10.10.20.10 sport=53422 dport=3389 src=10.10.20.10 dst=10.44.0.10 sport=3389 dport=53422 [ASSURED] mark=0 use=1

Signification : La session TCP RDP existe via la passerelle ; les paquets sont suivis et circulent.
Décision : Si vous ne voyez pas un flux établi quand l’utilisateur tente de se connecter, le problème est plus en amont (config client, routage, pare-feu).

Task 13: Check for MTU/fragmentation issues (classic “VPN works but RDP is awful”)

cr0x@server:~$ ping -c 3 -M do -s 1372 10.44.0.10
PING 10.44.0.10 (10.44.0.10) 1372(1400) bytes of data.
1380 bytes from 10.44.0.10: icmp_seq=1 ttl=64 time=34.2 ms
1380 bytes from 10.44.0.10: icmp_seq=2 ttl=64 time=33.5 ms
1380 bytes from 10.44.0.10: icmp_seq=3 ttl=64 time=33.9 ms

--- 10.44.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 33.5/33.8/34.2/0.3 ms

Signification : Un paquet de 1400 octets avec DF passe, ce qui suggère que le MTU n’est pas manifestement cassé sur ce chemin.
Décision : Si cela échoue avec « Frag needed », ajustez le MTU de WireGuard (souvent 1280–1420 selon les uplinks) et retestez.

Task 14: Verify Windows event logs show RDP logons (prove it’s auth vs network)

cr0x@server:~$ ssh admin@10.10.20.10 'powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName=\"Security\"; Id=4624} -MaxEvents 5 | Select-Object TimeCreated,Id,Message | Format-List"'
TimeCreated : 12/28/2025 3:41:02 PM
Id          : 4624
Message     : An account was successfully logged on.
...
Logon Type: 10
...

Signification : Logon Type 10 indique RemoteInteractive (RDP). Vous avez la preuve que l’utilisateur a effectivement atteint et authentifié l’hôte.
Décision : Si les utilisateurs se plaignent mais que vous voyez des connexions réussies, le problème est la performance de session, le chargement du profil, les GPO ou la lenteur d’une application — pas « VPN en panne ».

Task 15: Check failed logons and lockouts (brute force or fat-finger)

cr0x@server:~$ ssh admin@10.10.20.10 'powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName=\"Security\"; Id=4625} -MaxEvents 5 | Select-Object TimeCreated,Id,Message | Format-List"'
TimeCreated : 12/28/2025 3:39:11 PM
Id          : 4625
Message     : An account failed to log on.
...
Status: 0xC000006D
Sub Status: 0xC000006A
...

Signification : Substatus 0xC000006A indique typiquement mot de passe incorrect. Des événements répétés peuvent indiquer un brute force ou un utilisateur maladroit.
Décision : Si c’est un utilisateur réel, réinitialisez les identifiants ou corrigez les mots de passe enregistrés. Si c’est inconnu, investiguez l’IP source (IP VPN), désactivez le compte et cherchez des mouvements latéraux.

Task 16: Confirm RDP service is healthy and listening on Windows

cr0x@server:~$ ssh admin@10.10.20.10 'powershell -NoProfile -Command "Get-Service TermService | Format-Table Status,Name,DisplayName -AutoSize; netstat -ano | findstr \":3389\""'
Status Name        DisplayName
------ ----        -----------
Running TermService Remote Desktop Services
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1204

Signification : Le service RDP fonctionne et le port écoute.
Décision : Si le service est arrêté ou le port n’écoute pas, vous ne poursuivez pas des fantômes VPN — vous réparez l’hôte.

Playbook de diagnostic rapide (trouver le goulot vite)

Quand le bureau à distance est « en panne », le chemin le plus rapide est d’arrêter de le traiter comme un seul système. C’est quatre systèmes déguisés en un :
appareil client, VPN, chemin réseau et session Windows.

Première étape : le tunnel VPN est-il réellement en place ?

Sur la passerelle : wg show et vérifiez « latest handshake ».
Sur le client : confirmez qu’il a une IP VPN (ex. 10.44.0.x) et des routes pour les sous-réseaux internes.
Décision : si le handshake est stale, réparez la connectivité VPN (NAT, clefs, UDP bloqué). Ne touchez pas encore à Windows.

Deuxième étape : pouvez-vous joindre le jump host par IP sur 3389 ?

Depuis la passerelle ou un client test sur le VPN : nc -vz 10.10.20.10 3389.
Décision : si le port est fermé, c’est un pare-feu ou l’état du service. Si ouvert, poursuivez.

Troisième étape : DNS, authentification ou établissement de session ?

DNS : dig jump01... et comparez à l’IP interne attendue.
Auth : vérifiez les logs de sécurité Windows pour 4624/4625 autour du moment de la tentative.
Performance de session : si la connexion a réussi mais l’interface est inutilisable, suspectez MTU, perte de paquets, chargement de profil, profils itinérants ou scripts GPO.

Quatrième étape : si c’est lent, mesurez le réseau — ne devinez pas

Ping avec DF et tailles de paquets pour détecter le MTU.
Regardez les compteurs de transfert WireGuard et les erreurs d’interface.
Décision : si la latence est correcte mais l’UI lente, suspectez CPU/RAM/disque sur le serveur (oui, le stockage peut ruiner RDP).

Erreurs courantes : symptômes → cause → correction

1) Symptom : « RDP fonctionne sur le Wi‑Fi du bureau, échoue à distance »

Cause : Les règles pare-feu RDP autorisent les sous-réseaux LAN mais pas les sous-réseaux VPN ; ou les routes VPN ne sont pas poussées.
Correction : Scoppez les règles Windows Firewall « Remote Desktop » pour inclure 10.44.0.0/24, et assurez-vous que le serveur VPN route les réseaux LAN vers les clients.

2) Symptom : « Le VPN se connecte, mais le RDP par nom échoue ; l’IP fonctionne »

Cause : DNS non configuré pour les clients VPN, ou le split tunneling envoie les requêtes DNS vers des résolveurs publics.
Correction : Poussez les serveurs DNS internes dans la config VPN ; vérifiez avec dig contre le DNS interne et la config du résolveur client.

3) Symptom : « RDP demande les identifiants en boucle »

Cause : Mismatch NLA, dérive horaire affectant Kerberos, ou utilisation de comptes locaux avec politiques bloquant la connexion distante.
Correction : Exigez NLA, assurez-vous que les clients le supportent, corrigez la synchronisation horaire (NTP) et utilisez des comptes de domaine avec la bonne appartenance aux groupes.

4) Symptom : « RDP se connecte mais est extrêmement lent, surtout la frappe »

Cause : Problèmes MTU/fragmentation sur le VPN, perte de paquets, ou bufferbloat sur les uplinks.
Correction : Testez avec des pings DF ; ajustez le MTU WireGuard ; ajoutez QoS/traffic shaping ; évitez le hairpinning VPN si possible.

5) Symptom : « Déconnexions aléatoires toutes les quelques minutes »

Cause : Timeouts NAT et keepalive manquant pour les clients en roaming ; Wi‑Fi instable ; timeouts d’état de pare-feu agressifs.
Correction : Activez persistent keepalive WireGuard pour les clients derrière NAT ; investiguez le comportement du pare-feu/ISP ; privilégiez le filaire quand c’est possible.

6) Symptom : « Tout le monde peut RDP partout une fois sur le VPN »

Cause : Réseau plat + pare-feu permissif + appartenance AD large.
Correction : Implémentez la segmentation : clients VPN vers jump hosts uniquement ; groupes RDP au moindre privilège ; politiques forward deny-by-default.

7) Symptom : « La sécurité exige qu’on rotate les clés chaque semaine, maintenant plus rien ne marche »

Cause : Rotation sans automatisation ; clients hors synchronisation ; configs peer obsolètes.
Correction : Automatisez le provisioning/rotation ; utilisez de l’auth à courte durée quand possible ; versionnez les configs et déployez via gestion de poste.

Trois mini-histoires d’entreprise (parce que les cicatrices enseignent)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé un VPN pour « réparer » l’accès distant. Ils ont fait le strict nécessaire : serveur WireGuard, clés utilisateurs, un sous-réseau propre.
L’équipe a supposé que parce que les utilisateurs devaient s’authentifier au VPN, tout ce qui était derrière était « interne » et donc sûr.

Ils ont laissé les règles du pare-feu Windows pour RDP à leur portée par défaut (« Any »), et leur réseau interne était majoritairement plat.
Le helpdesk a adoré : moins de tickets. L’équipe sécurité n’a pas remarqué parce que rien n’était techniquement « exposé à Internet ».

Puis un portable de contractuel a été compromis via une faille de navigateur. L’attaquant n’a pas eu besoin de scanner Internet public.
Il s’est connecté au VPN avec le client déjà configuré du contractuel, est arrivé sur le sous-réseau VPN et a immédiatement commencé à sonder le RDP interne.
Quelques mots de passe faibles plus tard, il avait un poste de travail avec accès à des partages et à quelques outils d’admin.

La réunion post-incident a été discrètement brutale. Le problème n’était pas WireGuard. Le problème était l’hypothèse « VPN = de confiance ».
La correction a été tout aussi peu glamour : restreindre le trafic VPN vers les jump hosts, exiger la MFA et scoper les règles RDP du pare-feu à des sources spécifiques.
La sécurité a obtenu sa contention. Le helpdesk a reçu un nouveau script. Tout le monde a eu un runbook d’astreinte plus long.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre organisation avait des plaintes : « RDP est lent. » Ils ont regardé les graphiques de bande passante VPN, vu des pics, et ont décidé que le split tunneling réduirait « la charge ».
Ils ont poussé un changement de config un vendredi après-midi (évidemment) : seuls 10.10.0.0/16 passeraient par le VPN ; tout le reste sortirait localement.

Lundi matin : la moitié des utilisateurs ne pouvaient plus RDP par nom d’hôte. L’autre moitié pouvait se connecter mais avait des invites d’authentification étranges.
Ce n’était pas aléatoire. Certains réseaux domestiques détournaient le DNS. Certains utilisateurs avaient des résolveurs ISP « utiles ». Quelques-uns avaient des entrées DNS d’entreprise anciennes en cache.

Pire : un sous-ensemble d’utilisateurs avait maintenant des sessions RDP pendant que leur trafic Internet général contournait les contrôles d’entreprise.
Une infection par malware sur un réseau domestique avait un chemin plus propre vers le C2 alors que l’appareil infecté avait toujours une route vers le LAN via le VPN.
C’est le genre de phrase qu’on ne veut pas écrire dans un rapport d’incident.

Ils ont rollbacké le split tunneling pour la plupart des utilisateurs et ne l’ont réintroduit que pour un groupe strictement contrôlé avec endpoints gérés et ACL strictes.
La performance s’est améliorée plus tard, mais pas à cause du split tunneling. Elle s’est améliorée parce qu’ils ont corrigé les problèmes de MTU et mis en place du QoS sur l’uplink du bureau.
L’« optimisation » n’était pas fausse en théorie. Elle était fausse dans le contexte.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise réglementée faisait passer l’accès distant via VPN + une petite flotte de jump hosts Windows.
Chaque trimestre, ils faisaient quelque chose qui ressemblait à de la paperasse : ils revoyaient les appartenances aux groupes pour l’accès distant,
validaient les portées des pare-feu et testaient qu’aucun port RDP n’était joignable de l’extérieur.

Lors d’une revue, un ingénieur a remarqué qu’un nouveau sous-réseau avait été ajouté pour un environnement labo.
L’équipe de routage l’avait accidentellement annoncé largement, et une règle de pare-feu permissive signifiait que les clients VPN pouvaient désormais atteindre des serveurs de labo directement.
Les serveurs de labo, naturellement, étaient « temporaires », « expérimentaux » et patchés selon un calendrier qu’on qualifie d’« aspirational ».

Ils ont corrigé ça avant que ça ne devienne excitant : ont resserré les règles forward, mis à jour les groupes d’adresses et exigé que l’accès au labo passe par un jump host séparé avec des contrôles supplémentaires.
Deux semaines plus tard, une vulnérabilité est sortie pour l’UI de gestion de l’hyperviseur du labo. Le labo s’est fait scanner. Rien ne s’est passé.
Le meilleur incident est celui qui ne devient jamais un incident, et il est presque toujours évité par quelqu’un qui fait quelque chose d’ennuyeux exprès.

Listes de contrôle / plan étape par étape

Plan étape par étape pour déployer VPN + RDP en sécurité

Choisir un modèle d’accès distant : VPN + jump host pour la plupart des organisations ; RD Gateway si vous avez besoin d’un accès par application sans reach réseau complet.
Allouer des sous-réseaux : un sous-réseau client VPN dédié ; ne réutilisez pas des plages LAN ou vous le regretterez dans des cafés et hôtels.
Construire la passerelle VPN : OS durci, services minimaux, pipeline de patch, gestion de configuration.
Mettre en œuvre un forwarding deny-by-default : n’autorisez que les clients VPN à atteindre les jump hosts sur 3389 (et le DNS si nécessaire).
Déployer des jump hosts : petite flotte, baseline durcie, accès admin restreint, journalisation activée.
Verrouiller RDP sur les cibles : activer NLA, restreindre la portée du pare-feu, désactiver les chiffrements legacy quand possible, garder l’OS patché.
Ajouter la MFA : à l’entrée VPN, et idéalement aussi à la connexion Windows via un accès conditionnel ou des contrôles équivalents.
Centraliser les logs : logs VPN + logs de sécurité Windows + logs pare-feu au même endroit avec une rétention adaptée au risque.
Tester « pas de RDP public » en continu : scans externes planifiés ou supervision depuis un point de contrôle contrôlé.
Documenter le diagnostic rapide : le chemin d’astreinte doit prendre des minutes, pas une expédition archéologique sur Slack.

Checklist opérationnelle (hebdomadaire/mensuelle)

Confirmer que 3389 n’est pas ouvert sur les IP publiques (scan depuis l’extérieur).
Revoir la liste des pairs VPN et supprimer utilisateurs/appareils obsolètes.
Revoir les appartenances à « Remote Desktop Users » et aux Administrateurs locaux sur les jump hosts.
Patch des jump hosts et des passerelles VPN selon un calendrier réel.
Vérification ponctuelle des logs : authentifications VPN échouées, échecs RDP répétés, géos sources inhabituelles (si applicable).
Tester une vraie connexion distante depuis un réseau non bureau.

FAQ

1) Pourquoi exposer RDP à Internet est‑il si dangereux même avec des mots de passe forts ?

Parce que RDP est une cible haute valeur et se fait marteler par des scanners et du credential stuffing en permanence.
Les mots de passe forts aident, mais n’éliminent pas les vulnérabilités du protocole, les mauvaises configurations ou les identifiants volés.
Le RDP le plus sûr est celui qu’Internet ne peut pas atteindre.

2) Changer le port RDP n’est‑il pas suffisant ?

Non. Ça réduit le bruit des scanners paresseux, pas le risque face à quelqu’un de compétent.
Les attaquants scannent l’ensemble de l’espace de ports ou fingerprintent les services. Ne construisez pas la sécurité sur l’espoir qu’ils s’ennuieront.

3) Le VPN donne l’accès réseau complet aux utilisateurs. Puis‑je le limiter ?

Oui, et vous devriez. Le forward deny-by-default sur la passerelle VPN plus des règles explicites pour les jump hosts est la pratique standard.
Si votre produit VPN supporte des ACL par utilisateur, utilisez-les. Sinon, segmentez par groupes et sous-réseaux.

4) Dois‑je préférer UDP ou TCP pour le transport VPN ?

Préférez UDP quand c’est possible (WireGuard est UDP). TCP-over-TCP peut amplifier la latence et les comportements de retransmission.
Si vous êtes contraint au TCP par des réseaux captifs, envisagez un chemin d’accès alternatif, mais ne refondez pas tout pour du Wi‑Fi d’hôtel.

5) Ai‑je besoin d’un RD Gateway si j’ai déjà un VPN ?

Pas nécessairement. RD Gateway est utile quand vous avez besoin d’accès RDP sans routage réseau complet, ou quand les environnements clients bloquent les VPN.
Mais c’est un service public supplémentaire à exploiter. Si le déploiement VPN est faisable, VPN + jump hosts est plus simple et généralement plus sûr.

6) Comment empêcher un client VPN compromis de scanner mon LAN ?

Ne le laissez pas faire. Implémentez des règles de pare-feu pour que les clients VPN n’atteignent que des destinations et ports spécifiques (typiquement des jump hosts sur 3389).
Journalisez les refus. Envisagez des pools VPN admin séparés. Traitez les clients comme non fiables tant qu’ils n’ont pas prouvé le contraire.

7) RDP est lent uniquement via VPN. Quelle est la cause la plus courante ?

Les problèmes MTU et la perte de paquets sont des suspects majeurs. RDP est interactif ; de petits délais paraissent énormes.
Testez les pings DF, ajustez le MTU VPN et contrôlez la congestion d’uplink. Vérifiez aussi le serveur : contention disque et chargement de profil peuvent imiter une « lenteur réseau ».

8) Puis‑je me fier uniquement au pare-feu Windows ?

Vous pouvez, mais vous serez plus heureux si vous ne le faites pas. La défense en profondeur compte : pare-feu/NAT périmétrique, ACL passerelle VPN et portée du pare-feu Windows.
Le pare-feu Windows est utile, mais il suffit d’une erreur de politique pour se retrouver en « Any ».

9) Que faire des fournisseurs/contractuels qui ont besoin d’un accès temporaire ?

Donnez-leur accès à un jump host dédié avec des outils restreints et des identifiants temporels.
Évitez de leur donner des routes VPN larges. Journalisez leurs sessions. Retirez l’accès automatiquement à la fin du contrat (les rappels calendaires ne sont pas de l’automatisation).

10) La MFA sur le VPN suffit‑elle, ou faut‑il la MFA aussi sur Windows ?

La MFA au VPN est le minimum. La MFA sur Windows (ou l’accès conditionnel au niveau de la session) est préférable, surtout pour les utilisateurs privilégiés.
Le but est de rendre insuffisantes des identifiants VPN volés pour atteindre des postes sensibles ou des sessions admin.

Conclusion : prochaines étapes que vous pouvez réellement faire

Si vous voulez un bureau à distance sécurisé, arrêtez de penser à RDP comme au produit. Le produit est l’accès contrôlé.
Le VPN est la porte d’entrée. Le pare-feu est le couloir. Les jump hosts sont l’accueil. La journalisation est les images des caméras de sécurité dont vous aurez besoin plus tard.

Prochaines étapes qui font bouger la ligne cette semaine :

Scannez vos IP publiques et vérifiez que TCP/3389 est fermé/filtré partout.
Restreignez la portée RDP aux sous-réseaux VPN et idéalement seulement aux jump hosts.
Activez NLA et confirmez-le via registre/politique.
Ajoutez la MFA à l’accès VPN, et limitez les routes VPN à ce dont les utilisateurs ont réellement besoin.
Centralisez les logs pour les connexions VPN et les connexions RDP Windows afin de répondre avec des preuves, pas des impressions.

Deuxième blague, parce que vous l’avez méritée : Internet ne « découvre » pas un port RDP exposé ; il se contente de se rappeler où vous habitez.