RDP entre bureaux sans ports ouverts : la configuration sécurisée « RDP uniquement via VPN »

Ce que « RDP uniquement via VPN » signifie vraiment

« RDP uniquement via VPN » n’est pas une mode. C’est un ensemble concret de contrôles :

• Pas d’exposition publique de RDP. Pas de « sécurité par l’obscurité » avec un port différent. Pas de « seuls des IPs en liste blanche » sur le WAN. Juste non.
• RDP n’écoute que sur les interfaces internes (ou, plus concrètement, des règles de pare-feu imposent qu’il soit joignable uniquement depuis le sous‑réseau VPN).
• Le VPN est le seul chemin d’entrée d’Office A vers Office B pour le trafic de gestion.
• Contrôles d’identité et de poste sur le VPN, idéalement MFA et appareils liés par certificat.
• Journalisation exploitable. Pas une case à cocher. De la télémétrie réelle qui vous dit qui s’est connecté, d’où, et si ça a échoué.

Pourquoi « ouvrir 3389 » est professionnellement embarrassant

RDP est une cible de grande valeur. Ce n’est pas personnel ; c’est de l’économie. Les attaquants aiment RDP parce que c’est omniprésent, cela donne un accès interactif, et mène souvent directement au vol d’identifiants ou au ransomware.
L’exposer publiquement signifie que vos défenses doivent être parfaites tous les jours. Votre adversaire n’a besoin que d’un seul moment de fatigue de votre part.

Modèle de menace en un paragraphe

Les principaux risques sont le credential stuffing, les tentatives par force brute, l’exploitation de failles liées à RDP, le déplacement latéral une fois à l’intérieur, et la mauvaise configuration pure et simple.
Le VPN ne rend pas RDP « sécurisé ». Il rend RDP privé, ensuite vous durcissez RDP et le réseau environnant pour qu’une compromission ne devienne pas un événement global.

Une citation à garder sur un post‑it :
« L’espoir n’est pas une stratégie. » — Gen. Gordon R. Sullivan

Blague n°1 : Exposer 3389 sur Internet, c’est comme laisser la porte de votre bureau ouverte parce que vous avez acheté un paillasson plus joli. Les cambrioleurs adorent l’amélioration.

Faits intéressants et un peu d’histoire

Connaître le contexte vous aide à faire de meilleurs compromis. Voici quelques points concrets qui surprennent souvent même les équipes IT :

1. RDP existe depuis la fin des années 1990. Il vient de l’époque des Terminal Services de Microsoft, bien avant que le « zero trust » devienne un élément de présentation.
2. TCP/3389 est devenu une cible de scans parce qu’il est prévisible. L’automatisation d’attaque prospère sur les valeurs par défaut. Une grande partie du « bruit de fond » d’Internet, ce sont juste des bots qui frappent à cette porte.
3. Network Level Authentication (NLA) a changé la donne. NLA exige une authentification avant qu’une session bureau complète ne soit créée, réduisant l’abus de ressources et certaines classes de surface d’attaque pré-authentification.
4. Le vol d’identifiants, pas les bugs du protocole, est souvent la voie. Dans de nombreux incidents réels, RDP est juste le point d’entrée pratique après que des mots de passe ont été devinés ou réutilisés.
5. « Sécurité » et « utilisabilité » de RDP se battent constamment. Désactiver NLA ou autoriser d’anciens paramètres TLS arrive souvent parce qu’« une application fournisseur ne fonctionnera pas », et c’est ainsi que tout commence à pourrir.
6. Les VPN sont passés des appliances matérielles aux tunnels définis par logiciel. Les boîtiers IPsec étaient la norme ; désormais WireGuard et des piles IKEv2 modernes sont courants car les équipes ops veulent des configurations plus simples et observables.
7. « Changer le port RDP » n’est pas une vraie sécurité. Cela réduit le bruit aléatoire, pas les attaquants déterminés, et cela peut casser des outils et des audits.
8. La performance RDP dépend beaucoup de la latence et de la perte de paquets. La bande passante compte, mais 30–60 ms de latence et de faibles taux de perte peuvent faire que la session donne l’impression d’écrire dans de la pâte.

Choix d’architecture : site-à-site vs accès distant

Option A : VPN site-à-site entre bureaux (recommandé pour RDP « bureau à bureau »)

Si l’exigence est « d’Office A vers les serveurs d’Office B », un VPN site-à-site est le plus propre. Il crée un domaine de routage privé et contrôlé entre les deux réseaux.
Vous pouvez alors autoriser RDP uniquement depuis des sous‑réseaux sources spécifiques ou des jump hosts via ce VPN.

Vous obtenez un contrôle central, moins d’éléments mobiles sur les postes, et un routage prévisible. Vous prenez aussi la responsabilité de garder le routage strict pour que votre VPN ne devienne pas accidentellement un réseau plat qui permet tout partout.

Option B : VPN d’accès distant pour utilisateurs individuels

C’est le cas des « portables utilisateurs qui se connectent au siège ». C’est souvent nécessaire, mais ça change la problématique.
Vous validez alors l’état du poste, gérez le débat split‑tunnel, et traitez les réseaux itinérants. Ce n’est pas mauvais, juste différent.

Option C : RDP Gateway (utile, mais pas « sans ports ouverts »)

RDP Gateway encapsule RDP dans HTTPS et centralise l’accès. Cela peut être fait de façon sécurisée, mais cela exige typiquement d’exposer le port 443 (au minimum) sur Internet.
Si votre exigence est explicitement « pas de ports entrants ouverts », RDP Gateway n’est pas votre outil principal. C’est une architecture différente.

Recommandation orientée

Pour « entre bureaux », construisez un VPN site-à-site et appliquez « RDP uniquement depuis le sous‑réseau VPN » sur les pare‑feu Windows.
Ajoutez un jump host (ou mieux, deux) et faites en sorte que les administrateurs RDP sur le jump host, puis poursuivent. C’est ainsi que vous gardez RDP accessible tout en limitant le périmètre d’impact.

Base recommandée : WireGuard site-à-site avec listes d’autorisation RDP strictes

Topologie réseau de référence

• Office A LAN : 10.10.0.0/16
• Office B LAN : 10.20.0.0/16
• Sous‑réseau du tunnel WireGuard : 10.99.0.0/24
• Passerelle VPN Office A : office-a-vpn (Linux)
• Passerelle VPN Office B : office-b-vpn (Linux)
• Jump host Windows dans Office B : jump-b01 (10.20.10.10)
• Cibles RDP dans Office B : DCs/serveurs applicatifs selon besoin

Stratégie de routage qui ne vous jouera pas de mauvais tours plus tard

Gardez le tunnel étroit. Routez seulement ce dont vous avez besoin. Évitez « 0.0.0.0/0 via le tunnel » pour un site‑à‑site à moins d’aimer expliquer à la finance pourquoi les appels Teams ressemblent à un sous‑marin.

Le modèle propre :

• Office A route 10.20.0.0/16 via le tunnel.
• Office B route 10.10.0.0/16 via le tunnel.
• Le firewall Windows dans Office B autorise TCP/3389 seulement depuis 10.10.0.0/16 (ou, mieux, seulement depuis le sous‑réseau des jump hosts d’Office A).

NAT : évitez‑le sauf si nécessaire

Le NAT dans un VPN site-à-site crée des mystères futurs. Il peut être nécessaire si des sous‑réseaux se chevauchent (plus loin), mais si vous pouvez l’éviter, faites‑le.
Les VPN routés avec des sous‑réseaux distincts sont plus faciles à comprendre, à dépanner et à auditer.

Squelette de configuration WireGuard

WireGuard est volontairement simple. C’est un atout. La plupart des pannes ne viennent pas de WireGuard ; elles viennent du routage et du filtrage autour de lui.

cr0x@server:~$ sudo cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
PrivateKey = <redacted>

# Route Office B LAN through the tunnel
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT

[Peer]
PublicKey = <redacted>
AllowedIPs = 10.99.0.2/32, 10.20.0.0/16
PersistentKeepalive = 25

Remarquez ce qui compte : AllowedIPs est à la fois routage et politique. Si vous autorisez accidentellement 0.0.0.0/0, vous venez de dire à votre passerelle d’accepter « tout » de ce pair.
Ça peut aller en labo. En production, c’est un incident qui attend un stagiaire barbe‑noire avec Wireshark.

Durcissement de RDP : les éléments qui empêchent les incidents

1) Restreindre qui peut atteindre RDP (contrôles réseau)

Ne comptez pas sur les « mots de passe forts » comme première barrière. Votre première barrière est : seul le sous‑réseau VPN (ou un jump host) peut initier une poignée de main TCP.
Un RDP qui n’est pas joignable ne peut pas être attaqué par force brute.

2) Exiger NLA et un chiffrement moderne

Activez NLA. Faites respecter TLS. Désactivez les couches de sécurité legacy si vous le pouvez. Oui, vous trouverez un produit fournisseur ancien qui rouspète. Votre travail est de faire que ce soit leur problème, pas votre brèche.

3) Utiliser des jump hosts, pas « RDP partout »

Créez une enclave de gestion : un ou deux hôtes Windows durcis qui sont les seuls systèmes autorisés à RDP vers les serveurs.
Les admins RDP sur le jump host via le VPN, puis depuis le jump host vers les cibles internes.

Cela réduit l’exposition des identifiants (moins de postes touchant des contextes d’admin de domaine) et concentre la journalisation, ce qui la rend plus utile.

4) Identité : moindre privilège, MFA et workflows administratifs sensés

Le MFA a sa place sur le VPN. Si votre VPN ne peut pas faire de MFA, remplacez‑le ou placez une porte frontale aware‑identité devant lui.
Sur Windows, utilisez des comptes administrateurs séparés, retirez les adhésions inutiles au groupe Administrateurs locaux, et traitez l’accès RDP comme une permission contrôlée, pas comme un droit de naissance.

5) Journalisation et alertes : décidez ce que vous allez investiguer

Vous voulez savoir :

• Événements de pair VPN up/down et instabilité des handshakes.
• Connexions Windows réussies et échouées via RDP (logon type 10).
• Deniés de pare‑feu pour 3389 (pour voir les mauvais routages).

Gardez‑la exploitable. Journaliser tout sans rétention ni revue n’est que de l’oubli coûteux.

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

Ci‑dessous des tâches pratiques à exécuter sur les passerelles VPN Linux et les hôtes Windows pour valider « RDP uniquement via VPN », diagnostiquer la lenteur et vous prouver que vous n’avez pas construit une porte dérobée.
Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie et la décision que vous en tirez.

Task 1: Confirm WireGuard interface state

cr0x@server:~$ sudo wg show
interface: wg0
  public key: qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq=
  listening port: 51820

peer: ppppppppppppppppppppppppppppppppppppppppp=
  endpoint: 203.0.113.20:51820
  allowed ips: 10.99.0.2/32, 10.20.0.0/16
  latest handshake: 34 seconds ago
  transfer: 1.28 GiB received, 2.02 GiB sent
  persistent keepalive: every 25 seconds

Sens : La poignée de main est récente ; le scope de routage est limité à l’IP du tunnel + le LAN d’Office B. Les compteurs de transfert montrent du trafic réel.

Décision : Si « latest handshake » affiche des minutes/heures, corrigez la connectivité (UDP, NAT, IP de l’endpoint) avant de toucher à RDP.

Task 2: Validate kernel routes for remote LAN

cr0x@server:~$ ip route show | grep 10.20.0.0
10.20.0.0/16 dev wg0 proto static scope link

Sens : La passerelle enverra le trafic vers Office B dans le tunnel, pas vers la gateway par défaut.

Décision : Si cette route manque, RDP n’arrivera jamais. Corrigez AllowedIPs de WireGuard ou ajoutez des routes explicites.

Task 3: Confirm forwarding is enabled (site-to-site requires it)

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

Sens : L’hôte Linux routage entre interfaces.

Décision : Si c’est 0, activez le forwarding ; autrement votre VPN est une décoration coûteuse.

Task 4: Check firewall rules on the VPN gateway (forwarding path)

cr0x@server:~$ sudo iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -i wg0 -o eth0 -d 10.20.0.0/16 -j ACCEPT
-A FORWARD -i eth0 -o wg0 -s 10.20.0.0/16 -j ACCEPT

Sens : Drop par défaut avec des allow explicites entre wg0 et le LAN. Voilà à quoi ressemble un routage serré.

Décision : Si FORWARD est en DROP par défaut sans les règles allow, votre handshake sera up mais les paquets ne passeront pas. Ajoutez des règles spécifiques, pas un « ACCEPT all ».

Task 5: Verify NAT is NOT happening (unless you intended it)

cr0x@server:~$ sudo iptables -t nat -S | head
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT

Sens : Aucune règle NAT présente. Bon pour un routage propre et des journaux précis.

Décision : Si vous voyez des règles MASQUERADE pour le trafic VPN, confirmez que c’est requis (chevauchement de sous‑réseaux). Si ce n’est pas requis, retirez‑les pour éviter la confusion « qui est cette IP » plus tard.

Task 6: Test reachability to the RDP target port from Office A side

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

Sens : Le chemin réseau et le pare‑feu Windows permettent TCP/3389 depuis votre source.

Décision : Si ça time‑out, c’est routage/pare‑feu. Si c’est « refused », l’hôte est joignable mais le service RDP est arrêté ou bloqué localement.

Task 7: Confirm RDP is not reachable from the public internet (negative test)

cr0x@server:~$ nc -vz 198.51.100.45 3389
nc: connect to 198.51.100.45 port 3389 (tcp) failed: Connection timed out

Sens : Bien. L’IP publique ne répond pas sur 3389. Les timeouts sont généralement préférables à « refused » car ils révèlent moins.

Décision : Si cela réussit, stoppez tout. Vous avez exposé RDP. Fermez‑le au pare‑feu de bordure et vérifiez qu’aucun port‑forwarding ou règle de groupe de sécurité cloud ne fuit.

Task 8: Measure latency and loss over the tunnel (RDP feel depends on this)

cr0x@server:~$ ping -c 10 10.20.10.10
PING 10.20.10.10 (10.20.10.10) 56(84) bytes of data.
64 bytes from 10.20.10.10: icmp_seq=1 ttl=127 time=23.9 ms
64 bytes from 10.20.10.10: icmp_seq=2 ttl=127 time=24.1 ms
64 bytes from 10.20.10.10: icmp_seq=3 ttl=127 time=24.3 ms
64 bytes from 10.20.10.10: icmp_seq=4 ttl=127 time=24.0 ms
64 bytes from 10.20.10.10: icmp_seq=5 ttl=127 time=26.8 ms
64 bytes from 10.20.10.10: icmp_seq=6 ttl=127 time=24.2 ms
64 bytes from 10.20.10.10: icmp_seq=7 ttl=127 time=24.1 ms
64 bytes from 10.20.10.10: icmp_seq=8 ttl=127 time=24.3 ms
64 bytes from 10.20.10.10: icmp_seq=9 ttl=127 time=24.0 ms
64 bytes from 10.20.10.10: icmp_seq=10 ttl=127 time=24.4 ms

--- 10.20.10.10 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9018ms
rtt min/avg/max/mdev = 23.9/24.6/26.8/0.8 ms

Sens : 25 ms avec 0% de perte conviendra généralement pour RDP.

Décision : Si vous voyez une perte > 1% ou des pics de jitter, corrigez le réseau avant de blâmer les paramètres RDP.

Task 9: Check MTU-related pain (common with VPNs)

cr0x@server:~$ ping -c 3 -M do -s 1372 10.20.10.10
PING 10.20.10.10 (10.20.10.10) 1372(1400) bytes of data.
1372 bytes from 10.20.10.10: icmp_seq=1 ttl=127 time=25.1 ms
1372 bytes from 10.20.10.10: icmp_seq=2 ttl=127 time=25.3 ms
1372 bytes from 10.20.10.10: icmp_seq=3 ttl=127 time=25.2 ms

--- 10.20.10.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 25.1/25.2/25.3/0.1 ms

Sens : Le path MTU supporte des trames ~1400 octets. C’est typiquement sûr pour WireGuard.

Décision : Si cela échoue mais que des tailles plus petites fonctionnent, réduisez le MTU de WireGuard (p.ex. 1380) et retestez ; des blackholes MTU provoquent des gels aléatoires de RDP.

Task 10: Confirm Windows is listening on 3389 (from the Windows host via SSH or console)

cr0x@server:~$ ssh admin@10.20.10.10 "netstat -ano | findstr :3389"
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1140
  TCP    [::]:3389              [::]:0                 LISTENING       1140

Sens : TermService écoute sur IPv4 et IPv6, PID 1140.

Décision : Si rien n’écoute, le service RDP est arrêté ou désactivé. Démarrez le service et confirmez que la politique n’a pas désactivé RDP.

Task 11: Verify Windows firewall allows RDP only from the VPN/office subnet

cr0x@server:~$ ssh admin@10.20.10.10 "powershell -NoProfile -Command \"Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Get-NetFirewallAddressFilter | Select-Object -First 5\""
RemoteAddress : 10.10.0.0/16
RemoteAddress : 10.10.0.0/16
RemoteAddress : 10.10.0.0/16
RemoteAddress : 10.10.0.0/16
RemoteAddress : 10.10.0.0/16

Sens : Les règles RDP sont limitées au sous‑réseau d’Office A. C’est le point d’application « uniquement via VPN » que la plupart des auditeurs regardent.

Décision : Si vous voyez RemoteAddress : Any, resserrez cela. « Any » deviendra inévitablement « anyone » via un futur mauvais routage.

Task 12: Validate NLA is enabled

cr0x@server:~$ ssh admin@10.20.10.10 "powershell -NoProfile -Command \"(Get-ItemProperty -Path 'HKLM:\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp' -Name UserAuthentication).UserAuthentication\""
1

Sens : 1 signifie que NLA est requis.

Décision : Si c’est 0, activez‑le à moins d’avoir une raison de compatibilité très spécifique. Si un fournisseur insiste pour désactiver NLA, opposez‑vous fermement.

Task 13: Check Windows event logs for RDP logons (success/failure)

cr0x@server:~$ ssh admin@10.20.10.10 "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 3 | Select-Object TimeCreated, Id, Message\""
TimeCreated            Id Message
-----------            -- -------
12/28/2025 08:34:11 4625 An account failed to log on.
12/28/2025 08:32:07 4625 An account failed to log on.
12/28/2025 08:29:52 4625 An account failed to log on.

Sens : Des échecs de connexion existent. Corrélez maintenant l’IP source, le nom de compte et le type de logon. Si cela vient de l’intérieur du VPN, vous avez peut‑être des identifiants compromis ou un accès trop large.

Décision : Si vous voyez des rafales, resserrez l’accès VPN, activez le MFA, et examinez une politique de verrouillage de compte (avec prudence—les verrouillages peuvent être utilisés comme DoS).

Task 14: Confirm the VPN is the only path (routing sanity check)

cr0x@server:~$ traceroute -n 10.20.10.10 | head -n 6
traceroute to 10.20.10.10 (10.20.10.10), 30 hops max, 60 byte packets
 1  10.99.0.1  1.032 ms  0.981 ms  0.965 ms
 2  10.20.0.1  22.412 ms  22.376 ms  22.341 ms
 3  10.20.10.10  23.918 ms  23.882 ms  23.851 ms

Sens : Le trafic entre dans le tunnel et arrive dans Office B. Pas de détours étranges via des routes Internet.

Décision : Si le saut 1 est votre routeur ISP, vous ne passez pas par le VPN. Corrigez les routes et assurez‑vous que les hypothèses split‑tunnel correspondent à la réalité.

Task 15: Watch live traffic to confirm RDP flows are on the tunnel

cr0x@server:~$ sudo tcpdump -ni wg0 tcp port 3389 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
08:41:22.112233 IP 10.10.50.25.51432 > 10.20.10.10.3389: Flags [S], seq 12223344, win 64240, options [mss 1360,sackOK,TS val 111 ecr 0], length 0
08:41:22.134455 IP 10.20.10.10.3389 > 10.10.50.25.51432: Flags [S.], seq 99887766, ack 12223345, win 65160, options [mss 1360,sackOK,TS val 222 ecr 111], length 0
08:41:22.134900 IP 10.10.50.25.51432 > 10.20.10.10.3389: Flags [.], ack 1, win 64240, options [TS val 112 ecr 222], length 0
08:41:22.145000 IP 10.10.50.25.51432 > 10.20.10.10.3389: Flags [P.], length 64
08:41:22.150000 IP 10.20.10.10.3389 > 10.10.50.25.51432: Flags [P.], length 128

Sens : SYN/SYN-ACK sur wg0 prouve que la session traverse l’interface du tunnel VPN.

Décision : Si vous ne voyez pas de paquets ici mais que des utilisateurs prétendent faire du RDP, ils peuvent utiliser un autre chemin (outil distant de shadow IT, edge exposé, ou un autre VPN). Enquêtez et fermez la contournement.

Task 16: Identify bottleneck on the Linux gateway (CPU/interrupt pressure)

cr0x@server:~$ top -b -n 1 | head -n 15
top - 08:44:01 up 37 days,  2:11,  2 users,  load average: 0.62, 0.71, 0.68
Tasks: 141 total,   1 running, 140 sleeping,   0 stopped,   0 zombie
%Cpu(s):  7.2 us,  2.1 sy,  0.0 ni, 89.9 id,  0.1 wa,  0.0 hi,  0.7 si,  0.0 st
MiB Mem :   3932.1 total,    812.5 free,    701.1 used,   2418.5 buff/cache
MiB Swap:   1024.0 total,   1024.0 free,      0.0 used.   2978.2 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1890 root      20   0  131456  24192  10432 S   6.0   0.6  18:22.11 wg-quick
 1022 root      20   0       0      0      0 S   1.3   0.0  12:10.23 ksoftirqd/0

Sens : Beaucoup de marge CPU ; pas de signe que la passerelle soit le goulot d’étranglement.

Décision : Si le CPU est saturé ou que softirq est élevé, vous êtes peut‑être sous‑dimensionné ou avez des problèmes de NIC/driver. Scalez la passerelle ou ajustez les offloads (et testez).

Blague n°2 : Le VPN n’est pas « lent » ; il prend juste un itinéraire pittoresque et réfléchi. Malheureusement vos utilisateurs essaient de sprinter.

Protocole de diagnostic rapide

Quand quelqu’un dit « RDP est en panne », vous ne commencez pas par réinstaller Remote Desktop Services ou redémarrer le pare‑feu comme un rituel.
Vous suivez une séquence serrée qui trouve le goulot en quelques minutes.

Première étape : prouver que le chemin VPN est vivant

1. Vérifiez la poignée de main du tunnel. Si le tunnel n’est pas up, rien d’autre n’a d’importance. Utilisez wg show (Task 1) ou votre outil d’état IPsec.
2. Vérifiez les routes. Confirmez que le LAN distant route vers le tunnel (Task 2). Les mauvais routages ressemblent exactement à « RDP est en panne ».
3. Vérifiez le forwarding + pare‑feu sur les passerelles. Si le tunnel est up mais le forwarding bloque le trafic, vous verrez des handshakes mais pas de sessions (Tasks 3–4).

Deuxième étape : prouver que l’hôte cible est joignable et écoute

1. Test de reachabilité TCP vers 3389. Utilisez nc -vz (Task 6). Timeout vs refused vous indique où chercher.
2. Confirmez que le service écoute. netstat sur la cible (Task 10). Pas d’écouteur, pas de RDP.
3. Confirmez le scope du pare‑feu Windows. Assurez‑vous que les règles RDP sont limitées aux plages VPN/bureau (Task 11). Une règle trop serrée est aussi problématique qu’une trop permissive—simplement moins spectaculaire.

Troisième étape : diagnostiquer la « lenteur » avec la physique réseau, pas les impressions

1. Ping et perte/jitter. Task 8. La perte fait que RDP donne l’impression de perdre des frappes.
2. Test MTU. Task 9. Les blackholes MTU provoquent des pauses intermittentes que les utilisateurs décrivent comme « ça gèle parfois ».
3. Observer le trafic live du tunnel. Task 15. Si le trafic n’est pas sur wg0, l’utilisateur n’utilise peut‑être pas le chemin prévu.
4. Vérifiez la charge de la passerelle. Task 16. Le chiffrement et le forwarding demandent des ressources ; ne le faites pas tourner sur une VM oubliée à 1 vCPU en espérant le meilleur.

Que faire quand le tunnel est up mais que RDP échoue encore

À ce stade, concentrez‑vous sur les contrôles côté Windows :

• NLA activé (Task 12)
• Permissions de compte et memberships de groupe sensés (Remote Desktop Users vs Administrateurs locaux)
• Journaux d’événements pour les échecs (Task 13)
• Exactitude DNS (les clients se connectent à la bonne IP)

Trois mini-récits d’entreprise venus du terrain

1) L’incident causé par une mauvaise supposition : « C’est interne, donc c’est sûr »

Une entreprise de taille moyenne avait deux bureaux et un VPN site-à-site. Ils ont fait la « bonne chose » en n’exposant pas RDP publiquement.
Ils ont aussi fait la « chose classique » en autorisant RDP depuis « n’importe quel sous‑réseau interne » parce que c’était plus simple que gérer des règles.

La mauvaise supposition était subtile : ils traitaient le VPN comme si les deux côtés étaient magiquement dignes de confiance.
En pratique, Office A avait une pile d’appareils non gérés : un portable fournisseur qui passait, quelques PC kiosques, et un réseau Wi‑Fi qui n’était pas aussi segmenté qu’on le croyait.

Une tentative de credential stuffing contre un mot de passe d’admin local faible a réussi — pas parce que RDP était public, mais parce qu’il était joignable depuis trop d’endroits internes.
Une fois l’attaquant installé sur un serveur d’Office B, il a interrogé l’AD, pulvérisé des identifiants et progressé latéralement.

Le postmortem ne parlait pas d’exploits exotiques. Il parlait de portées et de frontières d’identité.
Ils ont corrigé cela en introduisant des jump hosts et en limitant les règles de pare‑feu RDP au seul sous‑réseau des jump hosts, plus en activant le MFA sur le VPN d’accès distant pour les administrateurs.
Le VPN est resté. Le modèle de confiance a changé.

2) L’optimisation qui s’est retournée contre eux : « Faisons du split‑tunneling pour les performances »

Une autre organisation recevait des plaintes légitimes : les sessions RDP semblaient lentes aux heures de pointe.
Quelqu’un a proposé le split‑tunneling pour tout le réseau du bureau : garder le trafic Internet local, ne router que les sous‑réseaux d’entreprise sur le VPN. Raisonnable sur le papier.

Le retour de bâton est venu de deux côtés. D’abord, le DNS est devenu ambigu : certains clients résolvaient des noms de serveurs en IP publiques à cause d’une configuration DNS mixte et de forwarders conditionnels mal appliqués.
Ensuite, la surveillance sécurité supposait que tout le trafic admin passait par l’interface du tunnel et n’a presque rien signalé quand des sessions sont arrivées par des sources inattendues.

Le résultat était étrange : certains admins se connectaient via le VPN comme prévu, d’autres utilisaient « accidentellement » un chemin alternatif via un outil distant tiers legacy toujours installé sur les jump hosts.
Les problèmes RDP sont devenus intermittents parce que les gens n’utilisaient pas le même chemin. Les tickets de support ressemblaient au folklore.

La correction n’a pas été « jamais de split tunneling ». Ce fut : définissez‑le précisément, appliquez le DNS, et retirez les outils contournants.
Ils ont implémenté un DNS conditionnel avec des règles claires, restreint le trafic de gestion au VLAN des jump hosts, et ajouté des alertes quand RDP venait de sous‑réseaux inattendus.
Les performances se sont améliorées, mais seulement après avoir restauré la déterminisme.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : « Une règle, une source, un but »

Une entreprise du secteur financier tenait une discipline stricte. Leur équipe réseau imposait des règles de pare‑feu terriblement spécifiques :
RDP vers les serveurs était autorisé uniquement depuis deux jump hosts, et ces jump hosts n’étaient joignables que via le VPN.

Cela semblait bureaucratique. Les gens se plaignaient de ne pas pouvoir simplement RDP depuis leur bureau « pour cinq minutes ».
L’équipe sécurité haussait les épaules et répétait la même phrase : « L’accès de gestion a un point d’étranglement. »

Puis le portable d’un prestataire a été infecté hors site et s’est connecté plus tard au réseau du bureau. Le malware a essayé la routine habituelle : scanner, se propager, forcer des mots de passe.
Il a pu voir beaucoup de choses, mais il n’a pas pu atteindre RDP sur les serveurs parce que les règles du pare‑feu Windows étaient strictement limitées aux jump hosts.

L’intervention a quand même demandé du travail — confinement, reimage, réinitialisation des credentials — mais elle n’a jamais dégénéré en prise de contrôle des serveurs.
La « règle ennuyeuse » n’a pas empêché le portable d’être infecté. Elle a empêché que l’infection devienne un événement fatal pour l’entreprise.
C’est le type d’ennui que vous voulez.

Erreurs courantes : symptôme → cause profonde → correction

1) Symptom: VPN shows “connected,” but RDP times out

Cause profonde : Le tunnel est up, mais les règles de forwarding ou de pare‑feu bloquent le trafic entre wg0 et le LAN (ou l’IP forwarding est désactivé).

Correction : Confirmez les routes (Task 2), activez le forwarding (Task 3), et ajoutez des allows FORWARD explicites (Task 4). Vérifiez avec tcpdump (Task 15).

2) Symptom: RDP works from some PCs but not others

Cause profonde : Plusieurs chemins existent (split tunnel, VPN alternatif, DNS obsolète, ou chemin direct Internet). Certains clients n’utilisent pas vraiment le VPN site-à-site.

Correction : Utilisez traceroute (Task 14) depuis les clients en échec et ceux qui fonctionnent, corrigez le routage/DNS, et supprimez les outils de contournement. Imposer le scoping des pare‑feu aux sous‑réseaux connus.

3) Symptom: RDP connects but randomly freezes for seconds

Cause profonde : Blackhole MTU ou perte de paquets intermittente sur le chemin du tunnel.

Correction : Lancez des probes MTU (Task 9) et des vérifs perte/jitter (Task 8). Baissez le MTU WireGuard, réparez les liens WAN, ou priorisez le trafic VPN en bordure.

4) Symptom: Users get credential prompts repeatedly, then “The logon attempt failed”

Cause profonde : NLA + mismatch de politique, skew d’horloge affectant Kerberos, ou restrictions de compte. Parfois l’utilisateur tente un compte local non autorisé pour RDP.

Correction : Confirmez le statut NLA (Task 12), consultez les journaux d’événements (Task 13), validez la synchronisation horaire, et assurez‑vous que l’utilisateur est dans Remote Desktop Users (ou équivalent) et autorisé par la politique.

5) Symptom: After “tightening security,” nothing can RDP anymore

Cause profonde : Scope RemoteAddress du pare‑feu Windows trop étroit (mauvais sous‑réseau), ou vous avez verrouillé les jump hosts eux‑mêmes.

Correction : Validez les filtres d’adresse du pare‑feu (Task 11), confirmez les plages d’IP source, et gardez un chemin de secours break‑glass (accès console / out‑of‑band) pour revenir sur des règles en toute sécurité.

6) Symptom: RDP is reachable from the internet despite “we didn’t open it”

Cause profonde : NAT/port‑forwarding en bordure, règle de groupe de sécurité cloud, ou modem ISP « utile » avec forwarding. Parfois un second pare‑feu fait de l’UPnP inattendu.

Correction : Effectuez un test négatif depuis l’extérieur (Task 7), puis auditez le NAT de bordure et les appareils en amont. Désactivez UPnP. Traitez toute exposition publique de RDP comme un incident et changez les identifiants.

7) Symptom: VPN is stable but RDP performance is awful only at certain times

Cause profonde : Bufferbloat ou saturation sur le WAN, ou la passerelle VPN est CPU contrainte sous charge.

Correction : Vérifiez la charge de la passerelle (Task 16), implémentez QoS/shape en bordure, et dimensionnez les passerelles avec de la marge. Ne sous‑dimensionnez pas le chiffrement sur une petite VM.

8) Symptom: RDP works, but audits complain “no MFA”

Cause profonde : Le MFA a été placé uniquement sur la connexion Windows (ou nulle part), alors que le risque principal est l’accès au service. L’authentification VPN est le bon point de contrôle.

Correction : Activez le MFA sur l’authentification VPN, restreignez l’accès VPN par groupe, et gardez RDP joignable seulement depuis le VPN/jump hosts.

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

Étape par étape : construire « RDP uniquement via VPN » entre deux bureaux

1. Inventaire des sous‑réseaux et correction des chevauchements. Si les deux bureaux utilisent la même plage RFC1918, décidez maintenant si vous renumérotez ou faites du NAT. Renuméroter est douloureux une fois ; le NAT est source de confusion pour toujours.
2. Choisir le type de VPN. Pour deux sites fixes, optez pour site‑à‑site (WireGuard ou IPsec/IKEv2). Favorisez ce que votre équipe peut opérer à 3h du matin.
3. Définir la plage IP du tunnel. Utilisez un petit /24 ou /30 réservé aux endpoints VPN (p.ex. 10.99.0.0/24).
4. Implémenter le routage. Ajoutez des routes pour les LAN distants vers le tunnel ; évitez le tunneling de route par défaut sauf si nécessaire.
5. Verrouiller le forwarding sur les passerelles. Drop par défaut, puis autoriser seulement le trafic requis entre sites (RDP vers jump hosts, AD/LDAP si besoin, monitoring, etc.).
6. Déployer les jump hosts. Durcissez‑les, patch‑ez‑les, monitorisez‑les. Ils sont votre point d’étranglement.
7. Scoper les règles du pare‑feu Windows. Autorisez TCP/3389 seulement depuis le sous‑réseau VPN ou celui des jump hosts. Préférez « autoriser seulement depuis les jump hosts » pour les serveurs.
8. Activer NLA et TLS moderne. Ne négociez pas avec des clients antiques ; mettez‑les à niveau ou isolez‑les.
9. Mettre MFA sur l’accès VPN. Faites du VPN la porte. Restreignez aussi quels utilisateurs/groupes peuvent se connecter.
10. Centraliser les journaux. Collectez les événements VPN et les journaux Windows Security pertinents pour RDP.
11. Exécuter des tests négatifs. Vérifiez que 3389 n’est pas joignable publiquement. Vérifiez que RDP échoue hors VPN.
12. Documenter le chemin. Écrivez les IPs source attendues, les IPs cibles et les ports autorisés. Le vous du futur vous remerciera.

Checklist opérationnelle : quoi monitorer en continu

• Uptime du tunnel VPN / fraîcheur des handshakes et churn
• Perte de paquets / jitter entre passerelles
• Échecs de logons Windows (4625) avec pics de logon type 10
• Journaux de refus de pare‑feu pour 3389 depuis des sources inattendues
• Conformité des patches sur les jump hosts et les cibles RDP

Checklist sécurité : ce qu’il faut interdire explicitement

• Pas d’entrée publique vers 3389, jamais
• Pas de scope « Any » dans les règles pare‑feu Windows Remote Desktop
• Pas de comptes administrateurs partagés pour RDP
• Pas de postes non gérés avec accès VPN admin
• Pas d’« exceptions temporaires » sans date d’expiration et responsable

FAQ

1) Est‑ce que « RDP uniquement via VPN » suffit, ou dois‑je quand même durcir RDP ?

Vous devez toujours durcir RDP. Le VPN limite qui peut atteindre le port ; le durcissement RDP limite ce qui se passe quand quelqu’un l’atteint.
Faites les deux. La défense en profondeur n’est pas un slogan ; c’est ce qui vous fait survivre aux rotations d’équipe.

2) Dois‑je utiliser WireGuard ou IPsec pour un site‑à‑site ?

Utilisez ce que votre équipe peut opérer de façon fiable. WireGuard est plus simple et souvent plus facile à déboguer. IPsec est largement supporté par les appliances et peut être « set and forget » bien fait.
Le protocole importe moins que le routage correct, le scoping des pare‑feu et le MFA sur les chemins d’accès.

3) Puis‑je juste changer le port RDP au lieu d’utiliser un VPN ?

Non. Changer de port réduit les scans aléatoires ; cela n’adresse pas les attaques ciblées, le credential stuffing ou la dérive de configuration.
Si vous devez exposer quelque chose publiquement, exposez une passerelle frontale identity‑aware hardenée — pas du RDP brut.

4) Ai‑je besoin d’un jump host si le VPN est déjà restreint ?

Si vous avez plus de quelques serveurs, oui. Les jump hosts créent un point d’étranglement pour le contrôle d’accès, les patches et la journalisation.
Ils réduisent aussi le nombre de postes qui manipuleraient des credentials privilégiés.

5) Quelle est la meilleure manière de restreindre RDP sur Windows ?

Scopez les règles du pare‑feu Windows pour « Remote Desktop » aux plages sources de confiance (sous‑réseau VPN ou jump hosts).
Ne comptez pas uniquement sur les pare‑feu de bordure ; les règles locales empêchent une exposition accidentelle via de futurs changements de routage.

6) Pourquoi RDP donne l’impression d’être lent bien que la bande passante soit suffisante ?

RDP est sensible à la latence et à la perte. Un lien rapide avec jitter et perte fera pire qu’un lien plus lent mais stable.
Vérifiez la perte/jitter du ping et les problèmes MTU d’abord (Tasks 8 et 9).

7) Devrions‑nous activer le split tunneling ?

Pour site‑à‑site, vous avez déjà un comportement « split » en ne routeant que les sous‑réseaux requis. Pour l’accès distant, le split tunneling est une décision de politique :
il peut réduire la charge et améliorer les performances, mais complique la surveillance et augmente le risque de chemins non désirés. Si vous le faites, définissez‑le précisément et testez scrupuleusement DNS et routage.

8) Que faire si les deux bureaux utilisent le même sous‑réseau (chevauchement) ?

Les sous‑réseaux qui se chevauchent sont la mine cachée classique. La solution propre est de renuméroter un site.
Si vous ne pouvez pas, vous devrez faire du NAT dans le VPN et du mapping soigné (par exemple traduire le 192.168.1.0/24 d’un site en une plage virtuelle non chevauchante). Documentez agressivement et attendez‑vous à du temps de dépannage supplémentaire pour toujours.

9) Comment prouver aux auditeurs que RDP n’est pas exposé publiquement ?

Fournissez des preuves de politique de pare‑feu (règles de bordure montrant aucun 3389 entrant), plus des tests négatifs externes (Task 7), plus le scoping du pare‑feu Windows (Task 11).
Les auditeurs aiment les contrôles en couches parce qu’ils supposent que des erreurs arrivent. Ils ont raison.

10) Peut‑on éviter RDP entièrement ?

Parfois. Pour l’administration serveur, PowerShell Remoting, Windows Admin Center ou des outils de gestion peuvent réduire l’usage interactif de RDP.
Mais vous voudrez toujours un chemin interactif de « break glass » pour les urgences — gardez‑le VPN‑seulement et strictement scoppé.

Conclusion : étapes pratiques suivantes

La configuration la plus sûre pour « RDP entre bureaux » n’est pas ingénieuse. Elle est disciplinée : VPN site‑à‑site, routage strict, scoping du pare‑feu Windows, jump hosts, MFA sur le VPN, et des journaux que vous lisez réellement.
Pas de 3389 ouvert. Pas d’exceptions qui persistent pour toujours. Pas de chemins mystérieux.

Faites cela ensuite, dans l’ordre :

1. Exécutez le test négatif depuis l’extérieur et confirmez que le RDP public est mort (Task 7).
2. Scoppez les règles de pare‑feu Windows RDP aux sources VPN/jump (Task 11) et vérifiez avec un test de reachabilité (Task 6).
3. Mettez en place (ou resserrez) le routage site‑à‑site et les règles de forwarding (Tasks 1–4).
4. Validez la latence/la perte et le MTU pour éviter les tickets « ça gèle parfois » (Tasks 8–9).
5. Installez le point d’étranglement : jump hosts, MFA, et journaux centralisés (Task 13 comme signal de départ).

Faites‑en quelque chose d’ennuyeux. Puis gardez‑le ennuyeux. C’est ainsi que la production reste vivante.