VPN + RDP/SSH : Accès distant sans ouvrir de ports sur Internet

Pourquoi vous ne devez pas ouvrir RDP/SSH sur Internet

Ouvrir RDP (3389) ou SSH (22) sur Internet, c’est comme laisser le lecteur de badges de votre bureau à l’extérieur du bâtiment, scotché à un lampadaire, avec un post‑it «s’il vous plaît, soyez normaux». Les gens ne seront pas «normaux».

Oui, vous pouvez durcir. Oui, vous pouvez bloquer par géo‑localisation. Oui, vous pouvez ajouter MFA. Mais vous annoncez quand même une surface d’attaque toujours accessible, globale et constamment scannée. Même si l’authentification est forte, le service devient une cible : bugs de protocole, problèmes pré‑authentification, rétrogradation étrange, credential stuffing, password spraying, et tout le chaos «c’est juste une preuve de concept» qui alimente les incidents de production.

Placer RDP/SSH derrière un VPN change la donne de trois manières :

• Accessibilité : les services ne sont plus atteignables publiquement, donc la plupart des attaques opportunistes ne démarrent jamais.
• Frontière d’identité : la première porte devient l’authentification VPN et la posture de l’appareil, pas le service cible.
• Observabilité : vous pouvez journaliser et limiter le débit en un point d’étranglement. Un seul endroit à consulter, un seul endroit à verrouiller.

Cela ne veut pas dire «VPN = sécurité absolue». Cela signifie que vous pouvez construire quelque chose de sensé : routage privé, moindre privilège et pistes d’audit qui ne ressemblent pas à un roman criminel écrit par un load balancer.

Faits intéressants et brève histoire

Le contexte compte. Une grande partie des douleurs d’accès distant d’aujourd’hui vient de décisions «on l’envoie» d’hier.

1. RDP n’a pas été conçu pour des réseaux hostiles. Il s’est développé dans des LAN et WAN d’entreprise, pas avec le modèle de menace Internet moderne.
2. SSH a remplacé telnet/rsh parce que le texte clair est mort. L’adoption précoce de SSH à la fin des années 1990 était une réponse pratique au problème «les gens peuvent renifler vos mots de passe».
3. IPsec précède la plupart des habitudes cloud. IPsec existe depuis les années 1990 ; beaucoup de débats VPN «nouveaux» sont d’anciennes discussions en vêtements modernes.
4. Les VPN SSL ont percé à cause du NAT. Quand tout est derrière du NAT et des pare‑feu, tunneliser sur TCP/443 est devenu une tactique de survie.
5. Les brute‑force RDP sont devenus une économie. Les botnets adorent scanner le 3389 parce que c’est rentable : identifiants, préparation de ransomware, mouvement latéral.
6. WireGuard est jeune mais volontairement minimaliste. C’est petit, rapide, cryptographie moderne et moins de réglages. Pour l’exploitation, c’est un avantage—moins d’états de configuration incohérents.
7. Le split tunneling est un vieux débat. La sécurité veut le désactiver. Le réseau veut l’activer. La réponse est généralement «ça dépend», mais moins souvent qu’on le croit.
8. Les bastions sont essentiellement une version moderne d’un jump box dial‑up. L’idée est ancienne : une porte contrôlée dans un réseau privé.
9. NLA (Network Level Authentication) a sauvé la réputation de RDP. Elle déplace l’authentification au début de la connexion, réduisant l’exposition à certaines classes d’attaques.

Une architecture de référence qui marche en production

Voici l’architecture que je recommande quand vous voulez de l’administration distante (RDP/SSH) sans ouvrir ces ports au monde. Elle s’adapte d’une PME de 10 personnes jusqu’à une multinationale qui a «trois produits VPN à cause de fusions».

Objectif : faire du réseau privé le seul réseau qui compte

L’idée centrale est simple : vos postes d’administration (laptops) rejoignent un VPN. Vos systèmes gérés (serveurs/postes) sont atteignables uniquement depuis l’espace d’adresses VPN ou des sous‑réseaux internes. RDP/SSH sont liés aux interfaces internes. Les pare‑feu font respecter cela.

Mouvement minimal (mais sans héroïsme)

• Passerelle VPN : WireGuard ou OpenVPN (ou IPsec), idéalement redondante.
• Fournisseur d’identité : au minimum comptes locaux + MFA ; mieux : intégration SSO au niveau VPN.
• Routage : soit VPN routé (L3) soit combinaison de routes politiques et NAT. Préférer le routé.
• Contrôle d’accès : plages IP autorisées par utilisateur ou par groupe ; idéalement appliquées dans le pare‑feu et/ou la config VPN.
• Journalisation : connexions/déconnexions VPN, événements d’authentification et métadonnées de session. Pour SSH, enregistrer les commandes quand c’est possible.

Où le jump host s’intègre (et où il n’apporte rien)

Certaines équipes opposent «VPN» et «bastion host». Ce n’est pas exclusif. Un schéma propre :

• Les utilisateurs se connectent au VPN.
• Ils ne peuvent atteindre qu’un jump host durci (SSH) et peut‑être une passerelle Remote Desktop.
• Depuis le jump host, ils atteignent des réseaux plus profonds selon le moindre privilège.

Cela réduit le rayon de propagation en cas de compromission d’un laptop et vous donne un endroit pour forcer l’enregistrement de session. Mais ne mettez pas un jump host juste pour éviter de corriger le routage. Ce n’est pas de l’architecture ; c’est de la pénitence.

Une citation à garder en tête : «L’espoir n’est pas une stratégie.» (idée souvent attribuée à des responsables opérationnels)

Options VPN qui ne vous détestent pas

WireGuard : mon choix par défaut pour l’accès d’administration moderne

WireGuard est petit, rapide et agressivement minimaliste. Pour l’exploitation, cela signifie moins d’états de configuration qui «fonctionnent parfois». Les clés sont statiques ; l’identité ressemble davantage à «cette clé d’appareil est autorisée». Vous pouvez superposer SSO et posture d’appareil en dehors de WireGuard si vous utilisez un contrôleur, mais même WireGuard simple est une base solide.

Compromis :

• Avantages : performance, stabilité, configs simples, cryptographie propre, routage facile.
• Inconvénients : la gestion des clés est de votre ressort à moins d’un plan de gestion ; la révocation consiste à «supprimer le peer» (ok mais il faut un processus).

OpenVPN : éprouvé, flexible, parfois bavard

OpenVPN reste courant parce qu’il fonctionne presque partout et supporte de nombreux mécanismes d’authentification. Il est plus lourd que WireGuard et peut être plus délicat à régler, mais il s’intègre bien aux environnements d’entreprise traditionnels.

Compromis :

• Avantages : écosystème mature, nombreuses intégrations d’authentification, option TCP/443 pour réseaux hostiles.
• Inconvénients : plus de réglages, complexité accrue, surcharge de performance.

IPsec (IKEv2) : excellent avec une bonne hygiène réseau

IPsec est excellent quand vous pouvez standardiser et que l’interopérabilité compte. Il est aussi pertinent pour des tunnels site‑à‑site entre réseaux plutôt que pour des admins individuels.

Le problème tient moins au protocole qu’à la réalité : les vendeurs interprètent différemment, le NAT traversal ressemble parfois au folklore, et le débogage peut devenir un concours de regard avec des captures de paquets.

Ne confondez pas «passerelle Remote Desktop» et «remplacement de VPN»

Les passerelles RDP peuvent être utiles. Elles peuvent aussi devenir une cible unique si vous les publiez sur Internet. Si vous exposez une passerelle publiquement, traitez‑la comme une API de production : OS durci, MFA, limitation de débit, TLS strict, patchs de vulnérabilité et journalisation constante. Sinon : gardez la passerelle derrière le VPN aussi.

Blague n°1 : Une règle de pare‑feu qui dit «temporaire» est la seule chose en informatique qui survit au matériel.

Identité, contrôle d’accès et «qui a fait quoi»

Authentification : faites du VPN la partie difficile

Si vous placez RDP/SSH derrière le VPN, la connexion VPN devient votre porte d’entrée. Renforcez‑la :

• MFA pour les utilisateurs VPN. Non optionnel. Si vous ne pouvez pas faire de MFA, vous ne faites pas d’accès distant ; vous jouez au casino à distance.
• Confiance de l’appareil si possible : appareils gérés uniquement, certificats, ou vérification de posture.
• Accès à durée limitée pour les fournisseurs et les urgences : comptes limités dans le temps ou appartenance temporaire aux groupes.

Autorisation : le routage est un système de permissions

La manière la plus simple de fuir de l’accès est de remettre un profil VPN qui route tout. Félicitations, vous avez construit un réseau plat avec du chiffrement plus joli.

Au lieu de cela :

• Définissez des pools d’adresses VPN par rôle (admins, support, fournisseurs).
• Restreignez quels sous‑réseaux internes chaque pool peut atteindre via des règles de pare‑feu sur la passerelle VPN et/ou des pare‑feu internes.
• Pour des environnements très sensibles, ajoutez une seconde porte : seul le jump host est atteignable, et cet hôte applique les accès par cible.

Audit : vous en aurez besoin plus tard, alors construisez‑le maintenant

«Qui s’est connecté, d’où et qu’ont‑ils touché ?» n’est jamais demandé pendant les semaines calmes. Vous l’entendrez quand quelque chose casse, ou quand le service juridique devient poliment intense.

Au minimum, collectez :

• Journaux de connexion VPN (identité utilisateur/appareil, IP source, IP VPN assignée, heure de début/fin).
• Journaux RDP sur Windows (événements de connexion, début/fin de session).
• Journaux d’authentification SSH et idéalement audit des commandes pour les accès privilégiés.

Renforcement de RDP et SSH une fois derrière un VPN

Lier les services aux interfaces internes

Votre état idéal : même si quelqu’un ouvre accidentellement un pare‑feu, le service n’écoute toujours pas sur l’interface publique. Défense en profondeur, pas défense par souhait.

Durcissement SSH qui compte vraiment

• Clés plutôt que mots de passe pour les comptes administrateurs.
• Interdire la connexion root via SSH. Utilisez sudo avec journalisation.
• Limiter les utilisateurs avec AllowUsers ou AllowGroups.
• Utiliser une cryptographie moderne (la plupart des réglages par défaut sont OK sur les distributions récentes ; ne soyez pas trop créatif).

Durcissement RDP qui compte vraiment

• Activer NLA et exiger une authentification forte.
• Utiliser le groupe Remote Desktop Users volontairement ; ne mettez pas «Domain Users» dedans parce que vous êtes fatigué.
• Limiter le partage du presse‑papier/disques si vous traitez des données sensibles. La commodité est la façon dont les données s’échappent.
• Patchs agressifs. Les bugs liés à RDP ne sont pas des objets de collection théoriques.

Segmenter les réseaux de gestion

Si possible, conservez un sous‑réseau de gestion dédié. Vos sous‑réseaux applicatifs de production ne devraient pas être l’endroit où les admins naviguent occasionnellement via RDP. C’est comme ça que les malwares apprennent votre cartographie interne.

Tâches pratiques avec commandes : vérifier, diagnostiquer, décider

Vous ne dépannez pas l’accès distant avec des sensations. Vous le dépannez avec des chemins de paquets, des tables de routage et des journaux. Ci‑dessous des tâches réelles à exécuter aujourd’hui. Chaque section inclut ce que signifie la sortie et la décision suivante.

Task 1: Confirm your VPN interface and assigned address (Linux)

cr0x@server:~$ ip -brief addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             203.0.113.10/24 fe80::1c2:abff:fe3d:111/64
wg0              UP             10.42.0.2/32

Ce que ça signifie : wg0 existe et a 10.42.0.2. S’il manque ou est DOWN, vous n’êtes pas «sur le VPN».

Décision : Si wg0 manque, démarrez le service et vérifiez la config ; s’il est UP mais aucun trafic ne circule, passez aux tâches de routage/pare‑feu.

Task 2: Check WireGuard handshake and last activity

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

peer: N7u2dX3XyqS3pWm0pYbV5z6mXh3q3wVxQe7zq7LwG3M=
  endpoint: 198.51.100.24:53321
  allowed ips: 10.42.0.1/32
  latest handshake: 34 seconds ago
  transfer: 42.11 MiB received, 18.07 MiB sent

Ce que ça signifie : Un handshake récent prouve la crypto et la connectivité de base. Les compteurs de transfert qui évoluent signifient que du trafic réel passe.

Décision : Si les handshakes sont périmés, vérifiez NAT/pare‑feu/portabilité UDP. Si les handshakes sont récents mais RDP/SSH échoue, c’est un problème de routage ou d’attachement du service.

Task 3: Validate route to an internal subnet via VPN

cr0x@server:~$ ip route get 10.10.20.15
10.10.20.15 dev wg0 src 10.42.0.2 uid 1000
    cache

Ce que ça signifie : Le noyau prévoit d’envoyer vers 10.10.20.15 via wg0.

Décision : Si ça indique dev eth0 ou «unreachable», corrigez AllowedIPs/routes VPN avant de toucher aux configs RDP/SSH.

Task 4: Test basic reachability (ICMP) and interpret carefully

cr0x@server:~$ ping -c 3 10.10.20.15
PING 10.10.20.15 (10.10.20.15) 56(84) bytes of data.
64 bytes from 10.10.20.15: icmp_seq=1 ttl=63 time=23.4 ms
64 bytes from 10.10.20.15: icmp_seq=2 ttl=63 time=22.9 ms
64 bytes from 10.10.20.15: icmp_seq=3 ttl=63 time=23.1 ms

--- 10.10.20.15 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 22.9/23.1/23.4/0.2 ms

Ce que ça signifie : Le chemin fonctionne et la latence est raisonnable. Si le ping échoue, ça peut encore aller : ICMP est souvent bloqué.

Décision : Si le ping réussit mais TCP ne passe pas, concentrez‑vous sur les ports de service et les pare‑feu. Si le ping échoue, passez à traceroute et aux règles de pare‑feu.

Task 5: Test TCP port reachability for SSH

cr0x@server:~$ nc -vz 10.10.20.15 22
Connection to 10.10.20.15 22 port [tcp/ssh] succeeded!

Ce que ça signifie : Quelque chose écoute et est joignable sur le port 22.

Décision : Si ça échoue, vérifiez l’état d’écoute local du service et les politiques de pare‑feu. N’ouvrez pas «globalement» ; ouvrez seulement depuis les CIDR VPN.

Task 6: Test TCP port reachability for RDP

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

Ce que ça signifie : RDP est atteignable sur l’adresse interne. Si le client RDP échoue encore, c’est un problème d’authentification/NLA/politique de certificat, pas de connectivité réseau.

Décision : Si ceci échoue mais que le ping marche, regardez un pare‑feu hôte, une ACL de sous‑réseau ou un service arrêté.

Task 7: Confirm SSH daemon listens only on internal/VPN interfaces (Linux)

cr0x@server:~$ sudo ss -lntp | grep ':22'
LISTEN 0      128        10.10.20.15:22        0.0.0.0:*    users:(("sshd",pid=923,fd=3))
LISTEN 0      128           10.42.0.10:22        0.0.0.0:*    users:(("sshd",pid=923,fd=4))

Ce que ça signifie : SSH écoute sur des adresses internes et VPN, pas sur 0.0.0.0:22 (toutes les interfaces).

Décision : Si vous voyez 0.0.0.0:22 sur un hôte avec interface publique, liez à des adresses spécifiques ou utilisez des règles de pare‑feu pour limiter strictement les sources.

Task 8: Validate firewall rules on the VPN gateway (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    iif "wg0" tcp dport { 22, 3389 } accept
    iif "wg0" icmp type echo-request accept
    tcp dport 51820 accept
    reject with icmpx type port-unreachable
  }
}

Ce que ça signifie : Politique par défaut drop. Seule l’interface VPN wg0 peut atteindre SSH/RDP sur cette passerelle. Le port WireGuard est autorisé.

Décision : Si vous voyez de larges acceptations sur iif "eth0" pour 22/3389, corrigez‑le. Si la politique est drop et que vous avez oublié ct state established, vous créerez un comportement «fonctionne 2 secondes».

Task 9: Check IP forwarding and rp_filter (classic routing footgun)

cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
net.ipv4.ip_forward = 1
net.ipv4.conf.all.rp_filter = 2

Ce que ça signifie : Le forwarding est activé. Le reverse path filtering est «loose» (2), généralement correct pour le routage VPN avec chemins asymétriques.

Décision : Si le forwarding est à 0 sur une passerelle routante, activez‑le. Si rp_filter est strict (1) et que vous voyez des trafics unilatéraux bizarres, mettez‑le à 2 sur les interfaces concernées.

Task 10: Verify NAT rules if you must NAT (iptables)

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.42.0.0/24 -o eth1 -j MASQUERADE

Ce que ça signifie : Les clients VPN dans 10.42.0.0/24 sont masqués quand ils sortent par eth1 vers des réseaux internes qui ne connaissent pas la route VPN.

Décision : Préférez ajouter des routes appropriées plutôt que du NAT. Mais si vous ne pouvez pas changer le routage interne rapidement, le NAT peut être une solution provisoire. Documentez‑le comme une arme chargée.

Task 11: Confirm the target Windows host is actually listening on RDP

cr0x@server:~$ sudo nmap -Pn -p 3389 10.10.30.25
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-27 10:20 UTC
Nmap scan report for 10.10.30.25
Host is up (0.024s latency).

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

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

Ce que ça signifie : Le port est ouvert. Si votre client RDP renvoie une erreur, c’est la négociation/auth/cert/NLA, pas un port fermé.

Décision : Si c’est fermé, vérifiez les règles du pare‑feu Windows, la stratégie de groupe et si le Bureau à distance est activé.

Task 12: Confirm SSH authentication failures vs network failures

cr0x@server:~$ ssh -vvv admin@10.10.20.15
OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 10.10.20.15 [10.10.20.15] port 22.
debug1: Connection established.
debug1: Authenticating to 10.10.20.15:22 as 'admin'
debug1: Offering public key: /home/cr0x/.ssh/id_ed25519 ED25519 SHA256:4tS...
debug1: Authentications that can continue: publickey
debug1: Authentication succeeded (publickey).
debug1: Entering interactive session.

Ce que ça signifie : Le réseau est OK et l’authentification a réussi. Si vous voyez des timeouts, c’est réseau/routage/pare‑feu. Si vous voyez «Permission denied», c’est clés/utilisateurs/politiques.

Décision : Dirigez les problèmes d’auth vers IAM/distribution de clés. Dirigez les timeouts vers réseau/SRE.

Task 13: Find where packets die (traceroute over VPN)

cr0x@server:~$ traceroute -n 10.10.20.15
traceroute to 10.10.20.15 (10.10.20.15), 30 hops max, 60 byte packets
 1  10.42.0.1  24.102 ms  23.881 ms  23.770 ms
 2  10.10.0.1  24.231 ms  24.021 ms  23.996 ms
 3  10.10.20.15  23.902 ms  23.912 ms  23.901 ms

Ce que ça signifie : Vous voyez la passerelle VPN et les sauts de routeur interne. Si ça s’arrête au saut 1, la passerelle ne peut pas router la suite.

Décision : Là où ça s’arrête est l’endroit à inspecter : table de routage, ACL ou route de retour manquante.

Task 14: Watch live traffic on the VPN gateway (tcpdump)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.42.0.2 and host 10.10.20.15 and tcp port 22
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:23:11.102334 IP 10.42.0.2.52144 > 10.10.20.15.22: Flags [S], seq 341234112, win 64240, options [mss 1420,sackOK,TS val 123 ecr 0], length 0
10:23:11.125883 IP 10.10.20.15.22 > 10.42.0.2.52144: Flags [S.], seq 91234122, ack 341234113, win 65160, options [mss 1360,sackOK,TS val 456 ecr 123], length 0

Ce que ça signifie : Vous voyez SYN et SYN‑ACK. Cela prouve que le trafic de retour existe au moins sur wg0. Si vous ne voyez que SYN, le chemin de retour est cassé.

Décision : Si le chemin de retour est manquant, vérifiez les routes internes vers le sous‑réseau VPN ou le comportement NAT.

Task 15: Confirm that internal networks have a route back to the VPN subnet

cr0x@server:~$ ip route | grep 10.42.0.0
10.42.0.0/24 dev wg0 proto kernel scope link src 10.42.0.1

Ce que ça signifie : La passerelle VPN sait que le sous‑réseau VPN est sur wg0. C’est nécessaire mais pas suffisant : les routeurs internes doivent aussi savoir où se trouve 10.42.0.0/24.

Décision : Si les routeurs internes n’ont pas de route de retour, ajoutez‑la (meilleur) ou du NAT (temporaire). Un VPN unidirectionnel est une perte de temps classique.

Task 16: Check OpenVPN server status if that’s your stack

cr0x@server:~$ sudo systemctl status openvpn-server@server
● openvpn-server@server.service - OpenVPN service for server
     Loaded: loaded (/lib/systemd/system/openvpn-server@.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-12-27 09:41:02 UTC; 42min ago
       Docs: man:openvpn(8)
   Main PID: 1234 (openvpn)
      Tasks: 1 (limit: 18954)
     Memory: 9.6M
        CPU: 1.214s

Ce que ça signifie : Il fonctionne. Si les utilisateurs ne peuvent pas se connecter, vérifiez les journaux et la configuration client, pas seulement l’état du service.

Décision : Si ce n’est pas actif, traitez‑le comme une panne : restaurer la config, valider certificats/clefs et confirmer les règles de pare‑feu.

Playbook de diagnostic rapide

Voici le playbook pour «le VPN est up mais je ne peux pas RDP/SSH» et vous avez besoin de réponses avant que votre café refroidisse.

Première étape : prouver que le VPN est réellement connecté et échange du trafic

• Vérifiez que l’interface existe et possède une IP (ip -brief addr).
• Vérifiez le handshake (WireGuard : wg show ; OpenVPN : status service + journaux).
• Vérifiez que les compteurs de transfert augmentent quand vous tentez une connexion.

Si le handshake est mort : regardez la joignabilité de l’endpoint VPN (pare‑feu, NAT, UDP bloqué, mauvais port).

Deuxième étape : vérifier le routage dans les deux sens

• Depuis le client : ip route get <target> doit indiquer qu’il utilise l’interface VPN.
• Depuis la passerelle VPN : confirmez qu’elle peut router vers le sous‑réseau cible.
• Depuis le routeur interne : confirmez qu’il a une route de retour vers le sous‑réseau VPN (ou que vous faites du NAT volontairement).

Si vous voyez SYN mais pas SYN‑ACK : routage de retour ou pare‑feu du côté distant. Si vous voyez SYN‑ACK sur wg0 mais que le client timeout, vous pouvez avoir des problèmes de MTU ou un pare‑feu local.

Troisième étape : vérifier que le service est atteignable et écoute là où vous pensez

• Accessibilité des ports : nc -vz host 22 / nc -vz host 3389.
• Sur la cible : confirmer l’adresse d’écoute (ss -lntp sur Linux ; pare‑feu/service Windows pour Windows).
• Valider que le pare‑feu hôte autorise le trafic depuis le CIDR VPN.

Quatrième étape : isoler les goulots de performance (latence, MTU, DNS)

• Latence : ping ou temps de connexion TCP, puis traceroute.
• MTU/MSS : symptômes «se connecte puis gèle» ou «écran RDP noir».
• DNS : si le nom échoue mais l’IP fonctionne, corrigez le split‑DNS ou poussez des resolvers internes.

Erreurs courantes : symptôme → cause racine → correction

1) «Le VPN se connecte, mais je n’atteins rien en interne.»

Symptôme : Le VPN indique connecté ; vous pouvez pinguer la passerelle VPN mais pas les hôtes internes.

Cause racine : Routes manquantes (AllowedIPs trop restreints, ou routeurs internes ignorent le sous‑réseau VPN).

Correction : Ajoutez des routes pour les sous‑réseaux internes dans la config client VPN et ajoutez une route de retour sur les routeurs internes (préférable) ou NAT sur la passerelle (temporaire).

2) «SSH fonctionne vers certains hôtes mais pas d’autres, de façon aléatoire.»

Symptôme : Certains sous‑réseaux fonctionnent, d’autres timeout ; comportement incohérent.

Cause racine : Plages IP qui se chevauchent (pool VPN qui entre en collision avec des plages internes) ou routage asymétrique via plusieurs sorties.

Correction : Réattribuez le pool VPN à un espace non‑chevauchant ; assurez la symétrie du routage interne ou utilisez du policy routing sur la passerelle.

3) «RDP se connecte puis écran noir / blocage.»

Symptôme : TCP 3389 est joignable, mais la session se fige.

Cause racine : Problèmes MTU/MSS sur le tunnel, ou inspection de sécurité agressive qui altère le trafic.

Correction : Réduisez l’MTU du tunnel ; bloquez MSS sur la passerelle ; évitez le TCP-over-TCP sauf contrainte réelle.

4) «On n’expose que le port VPN ; on s’est quand même fait compromettre.»

Symptôme : Le seul port public est le VPN, pourtant l’attaquant est entré.

Cause racine : Auth VPN faible (pas de MFA), clés fuitées, comptes partagés, ou poste compromis avec des identifiants valides.

Correction : Imposer MFA, faire tourner clés/certs, révoquer rapidement les peers, exiger des appareils gérés et restreindre ce que les clients VPN peuvent atteindre.

5) «Le DNS marche pour Internet mais pas pour les noms internes via le VPN.»

Symptôme : Vous pouvez SSH par IP, mais pas par nom d’hôte ; les noms internes ne résolvent pas.

Cause racine : Split‑DNS non configuré ; le VPN ne pousse pas les serveurs DNS internes ou les domaines de recherche.

Correction : Poussez des serveurs DNS internes et des domaines de recherche via la config VPN ou la politique client. Ne comptez pas sur des fichiers hosts manuels.

6) «Les performances sont terribles seulement sur le VPN.»

Symptôme : Latence élevée, RDP saccadé, SCP lent.

Cause racine : Routage en épingle à cheveux (tout revient via le siège), CPU de passerelle surchargé, attentes erronées d’accélération crypto ou perte de paquets sur le chemin UDP.

Correction : Utilisez le split tunneling avec prudence pour le trafic non‑corporate, ajoutez des passerelles régionales, surveillez le CPU des gateways et vérifiez la perte de paquets avec les compteurs tcpdump.

7) «Après avoir ‘durci’ SSH, l’automatisation a cassé.»

Symptôme : Les jobs CI/CD échouent à SSH après un changement de sécurité.

Cause racine : Auth par mot de passe désactivée sans provisionner de clés, ou restrictions de groupes/utilisateurs trop larges.

Correction : Déplacez l’automatisation vers des comptes de service dédiés avec clés scellées ; testez les changements dans un environnement de staging qui reflète l’auth de production.

8) «L’accès fournisseur devient permanent.»

Symptôme : De vieux comptes VPN fournisseurs fonctionnent encore des mois après.

Cause racine : Pas de workflow d’offboarding ; l’accès est accordé par exception et jamais revu.

Correction : Limitez dans le temps les comptes fournisseurs, imposez des revues périodiques d’accès et exigez des références de ticket dans les métadonnées de compte.

Trois mini‑histoires d’entreprise depuis le terrain

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

Une entreprise de taille moyenne a déplacé une appli comptable legacy dans un environnement hébergé. L’équipe ops était fière : pas de RDP public, pas de SSH public, juste un VPN. Ils avaient en grande partie fait le bon choix. Puis la semaine de paie est arrivée et les sessions RDP ont commencé à se couper toutes les quelques minutes.

L’hypothèse était simple et fausse : «si le VPN est connecté, le chemin réseau est correct.» L’équipe a cherché du côté des mises à jour Windows, des réglages RDP et des laptops des utilisateurs. Quelqu’un a même suggéré d’augmenter les timeouts RDP, ce qui est une belle façon de perdre du temps en confiance.

Le vrai problème était le routage de retour. La passerelle VPN pouvait atteindre les serveurs. Les serveurs pouvaient répondre, mais leur gateway par défaut envoyait le trafic vers un autre routeur qui n’avait aucune idée d’où se trouvait le sous‑réseau VPN. La moitié du trafic prenait une route de tourisme vers un trou noir. Ça ressemblait à des «déconnexions aléatoires» parce que c’en était.

La correction a été ennuyeuse : ajouter une route pour le sous‑réseau VPN sur le routeur interne approprié. Les coupures RDP ont disparu immédiatement. Le postmortem fut bref : ne jamais supposer que «connecté» signifie «routable dans les deux sens».

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une plus grande organisation cherchait à améliorer la performance VPN. Leur équipe réseau a déplacé le service VPN pour qu’il fonctionne sur TCP/443 parce que «ça passe tous les pare‑feu». C’était présenté comme une amélioration de fiabilité. C’était aussi un piège.

La première semaine semblait bien. Puis un bureau régional a commencé à se plaindre que les transferts de fichiers et RDP étaient lents. Pas seulement lents—collants, en rafales et imprévisibles. Les captures montraient des retransmissions et du head‑of‑line blocking.

Ils avaient construit du TCP‑sur‑TCP : un tunnel TCP transportant des applications TCP. Quand il y a perte, TCP tente de récupérer ; votre TCP interne tente aussi de récupérer. Les mécanismes de récupération se combattent et vos utilisateurs obtiennent un diaporama.

La correction a été de revenir à UDP pour le VPN quand c’est possible et de réserver TCP/443 en dernier recours. Les performances se sont stabilisées et l’«optimisation» a été discrètement retirée du diagramme d’architecture.

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

Une entreprise réglementée avait une règle stricte : chaque utilisateur VPN appartient à un groupe, chaque groupe mappe à un accès réseau explicite, et tout changement d’accès nécessite un ticket. Tout le monde détestait ça en période calme car c’est frictionnant. L’équipe sécurité aimait bien cette friction. Ils trouvaient ça relaxant.

Un après‑midi, l’ordinateur portable d’un ingénieur a été volé dans une voiture. Le laptop était chiffré, mais l’équipe IR a supposé le pire : l’appareil pourrait être compromis plus tard. La question est devenue : «Que peut atteindre cet appareil maintenant ?»

Parce que le modèle d’accès était ennuyeux et explicite, la réponse est venue tout de suite. Le profil VPN de l’ingénieur ne routait que vers un sous‑réseau de jump host, pas vers les bases de données de production. La révocation d’accès a été une suppression de peer en une ligne, et le jump host exigeait déjà MFA et des identifiants à courte durée.

Ils ont tourné les clés concernées, revu les journaux et sont passés à autre chose sans une semaine de panique. La règle que tout le monde critiquait a fini par transformer l’incident en simple ticket, pas en gros titre.

Blague n°2 : La seule chose plus persistante que les attaquants, c’est un stagiaire qui a appris le port forwarding hier.

Listes de vérification / plan étape par étape

Plan A : Le choix sensé par défaut (VPN + routage + sous‑réseaux restreints)

1. Choisir un CIDR VPN non chevauchant (exemple : 10.42.0.0/24). Notez‑le. Traitez‑le comme un contrat d’API.
2. Déployer des passerelles VPN avec pare‑feu par défaut deny. N’exposez publiquement que le port VPN.
3. Activer le MFA pour l’accès VPN. Si votre produit VPN ne le supporte pas, c’est une demande de changement.
4. Définir l’accès basé rôle : les admins peuvent atteindre les sous‑réseaux de gestion ; le support a des endpoints limités ; les fournisseurs ont un accès limité dans le temps à des hôtes spécifiques.
5. Pousser le DNS interne aux clients VPN et configurer le split‑DNS si nécessaire.
6. Ajouter des routes de retour sur les routeurs internes pour le CIDR VPN via la passerelle VPN. Évitez le NAT sauf nécessité.
7. Lier SSH/RDP aux interfaces internes et verrouiller les pare‑feu hôtes pour n’autoriser que le CIDR VPN ou les jump hosts.
8. Centrer les journaux : journaux d’auth VPN, journaux de sécurité Windows, journaux SSH. Mettre des alertes sur les motifs suspects.
9. Tester depuis un client propre : nouveau profil VPN, vérifier le routage, vérifier la reachabilité des ports, vérifier l’authentification.
10. Documenter la procédure «break glass» : qui peut obtenir un accès d’urgence, comment il est approuvé et comment il est révoqué.

Plan B : Ajouter un jump host quand vous avez besoin d’un contrôle plus strict

1. Les utilisateurs se connectent au VPN, mais ne peuvent atteindre qu’un sous‑réseau de jump host.
2. Le jump host réimpose MFA/SSO, avec journalisation stricte et enregistrement de session si possible.
3. Depuis le jump host, autoriser SSH/RDP vers les cibles selon l’appartenance aux groupes.
4. Refuser les routes directes client→production. Pas d’exceptions «juste pour moi». Les exceptions deviennent une culture.

Plan C : Accès fournisseur sans chaos

1. Créer des profils VPN spécifiques aux fournisseurs avec limites temporelles et AllowedIPs étroits.
2. Forcer l’accès via un jump host avec sessions enregistrées.
3. Désactiver le split tunneling pour les profils fournisseurs si possible ; au minimum bloquer l’accès aux ressources internes non nécessaires.
4. Revoir l’accès fournisseur régulièrement ; révoquer automatiquement à la fin de contrat.

FAQ

1) Un VPN suffit‑il, ou faut‑il quand même durcir SSH/RDP ?

Durcissez quand même. Le VPN réduit l’exposition ; il n’élimine pas le risque interne, les postes compromis ou le mouvement latéral. Traitez le VPN comme une porte, pas comme un champ de force magique.

2) Dois‑je désactiver le split tunneling ?

Par défaut, désactivez‑le pour les profils d’administration. Si vous devez l’activer, restreignez les sous‑réseaux internes atteignables et surveillez le DNS attentivement. La plupart des incidents «split tunnel» sont en réalité des incidents «split brain DNS».

3) Qu’est‑ce qui est mieux : VPN ou bastion ?

Pour les petites équipes, un VPN seul suffit si l’accès aux sous‑réseaux est restreint. Pour une assurance plus élevée, utilisez les deux : VPN pour entrer dans le réseau privé, bastion/jump host pour contrôler et enregistrer la suite.

4) Pourquoi ne pas juste changer SSH sur un port non standard et en finir ?

Parce que les scanners peuvent compter jusqu’à 65535. Changer de port réduit le bruit, pas le risque. Si votre objectif est «ne pas être attaqué», se cacher n’est pas une stratégie ; isoler l’est.

5) Puis‑je garder RDP/SSH ouverts mais limiter par liste d’IP ?

Parfois. C’est quand même fragile parce que les IP domestiques changent, les réseaux mobiles changent et vous finirez par autoriser des plages plus larges que prévu. Le VPN vous donne une identité stable et une entrée contrôlée unique.

6) Quelle est la cause numéro un de «le VPN est up mais rien ne marche» ?

Routes de retour manquantes. Le côté VPN sait où envoyer les paquets, mais les réseaux internes ne savent pas comment répondre au sous‑réseau VPN.

7) Comment gérer l’accès d’urgence si le VPN est en panne ?

Concevez‑le explicitement : console hors‑bande, plan de gestion séparé ou une seconde passerelle/provider VPN. Ne gardez pas SSH/RDP publics «au cas où». C’est comme ça que le «au cas où» devient «on vient de se faire compromettre».

8) WireGuard est‑il sûr pour l’usage entreprise ?

Oui, si vous gérez correctement les clés et l’accès. Sa simplicité est un avantage opérationnel. La question d’entreprise porte généralement sur le cycle de vie : onboarding, offboarding, audit et application de politiques.

9) Et les réseaux de stockage/administration—préoccupations particulières ?

Oui : l’accès de gestion aux systèmes de stockage a un fort impact. Gardez les interfaces de gestion de stockage sur des sous‑réseaux dédiés accessibles uniquement via VPN et idéalement via un jump host. Auditez fortement.

10) Comment prouver que nous n’exposons plus RDP/SSH ?

Exécutez des scans externes depuis l’extérieur de votre périmètre réseau et vérifiez que les ports 22 et 3389 sont fermés. En interne, confirmez que les services sont liés à des interfaces privées et que les pare‑feu restreignent les sources aux CIDR VPN.

Prochaines étapes réalisables cette semaine

1. Inventairez l’exposition : identifiez tout SSH/RDP exposé publiquement et fermez‑le. Si vous ne pouvez pas fermer immédiatement, restreignez par IP source et ajoutez MFA pendant la migration.
2. Lancez un pilote VPN : choisissez un CIDR non‑chevauchant, déployez une passerelle, connectez deux admins, routez vers un sous‑réseau de gestion.
3. Corrigez le routage proprement : ajoutez des routes de retour sur les routeurs internes plutôt que de compter sur le NAT, sauf exception documentée.
4. Durcissez les cibles : liez SSH/RDP aux interfaces internes, imposez clés/NLA et restreignez les règles hôtes aux CIDR VPN.
5. Écrivez le runbook : copiez le Playbook de diagnostic rapide dans vos docs on‑call et ajoutez les plages IP et interfaces spécifiques à votre environnement.
6. Rendez la révocation rapide : exercez‑vous à supprimer un peer/utilisateur VPN et vérifiez qu’il est coupé. Si la révocation prend une heure, ce n’est pas une révocation ; c’est une réunion.

Si vous ne faites rien d’autre : cessez de publier les protocoles d’administration sur Internet. Mettez‑les derrière un VPN avec une authentification forte et un routage serré. Votre futur vous enverra des remerciements via la seule machine à remonter le temps fiable : moins d’incidents.