Sécurité VPN : 12 erreurs qui transforment un « tunnel privé » en incident

Faits intéressants et contexte historique

• « VPN » a commencé comme un outil de connectivité d’entreprise, pas comme un produit de confidentialité. Les premiers designs visaient les liens site‑à‑site entre bureaux, où la « confiance des points d’extrémité » était supposée.
• La normalisation d’IPsec a démarré au milieu des années 1990. Elle a résolu le chiffrement « sur le fil » mais pas « empêcher un point d’extrémité compromis de gâcher votre journée ». Cette partie reste de votre ressort.
• PPTP (un protocole VPN ancien) a été largement déployé malgré un chiffrement faible. C’est un rappel que la commodité peut survivre à la correction pendant des périodes embarrassantes.
• Les VPN TLS sont devenus populaires parce qu’ils traversent facilement NAT et pare‑feux. Ce gain d’usage a aussi rendu les accès distants des cibles attractives : un port exposé à Internet avec un large rayon d’impact.
• Le split tunneling était à l’origine une optimisation de bande passante quand acheminer tout le trafic Internet sur les liens d’entreprise coûtait cher. Aujourd’hui, c’est souvent un compromis de sécurité déguisé en « performance ».
• Les fuites DNS étaient connues depuis des années parce que les systèmes d’exploitation essaient d’« être utiles » avec les résolveurs, les métriques d’interface et les comportements de secours. Utile n’est pas synonyme de sûr.
• Les durées de vie des certificats étaient autrefois mesurées en années car la rotation était opérationnellement pénible. L’automatisation a rendu les durées courtes réalistes ; beaucoup d’organisations conservent encore des certificats de 5 ans par habitude.
• Le design de WireGuard est volontairement petit (quelques milliers de lignes de code cœur comparé à des piles héritées plus larges). Plus petit ne veut pas dire parfait, mais ça change la surface d’audit et de défaillance.
• Beaucoup d’incidents VPN majeurs n’ont pas commencé par un « chiffrement cassé » ; ils ont commencé par des interfaces de gestion exposées, des appliances non patchées, ou des identifiants réutilisés entre systèmes.

Deux choses ne changent jamais : les gens ont trop confiance dans les tunnels, et les attaquants adorent tout composant exposé à Internet, authentifié et connecté aux réseaux internes.

Playbook de diagnostic rapide (trouver le goulot d’étranglement vite)

Quand un VPN « tombe », il faut décider : avons‑nous affaire à la connectivité, à l’authentification, au routage, au DNS, à la performance ou à la politique ? Voici comment éviter de passer deux heures à blâmer « le VPN » comme s’il était une entité pensante.

Premier point : établir ce qui échoue (plan de contrôle vs plan de données)

1. Les clients atteignent‑ils l’écouteur VPN ? Vérifiez la reachabilité réseau basique et le statut du service.
2. Les clients peuvent‑ils s’authentifier ? Si le MFA/IdP est instable, le tunnel ne se forme jamais. Si les certificats sont expirés, même résultat.
3. Le trafic passe‑t‑il après la connexion ? Là, c’est routage, politiques de pare‑feu, MTU, DNS ou configuration split‑tunnel.

Second point : identifier si le problème est global ou limité

1. Un seul utilisateur ? Posture de l’endpoint, pare‑feu local, config client obsolète, portail captif Wi‑Fi, cache DNS, dérive d’horloge.
2. Un bureau/région ? Routage ISP, points de terminaison IdP géo‑restreints, bizarreries anycast, ou un POP en panne.
3. Tout le monde ? Épuisement des ressources serveur, expiration de certificats, panne d’IdP, push de règles de pare‑feu, ou une mise à jour du noyau qui « ne devrait pas » affecter le réseau.

Troisième point : localiser le goulot avec trois signaux peu coûteux

1. CPU serveur (crypto, traitement de paquets, orages d’interruptions).
2. Paquets perdus (files NIC, conntrack, pare‑feu, MTU).
3. Journaux autour de l’auth (limites de débit, verrouillages, MFA échoués, certificats invalides).

Idée paraphrasée de Werner Vogels : on construit des systèmes fiables en supposant que tout échoue et en concevant en conséquence. Les VPN ne font pas exception.

Blague n°1 : Un VPN, c’est comme un videur : si vous laissez tout le monde entrer sans demander d’identité, vous avez construit une porte très polie.

Les 12 erreurs (et quoi faire à la place)

1) Prendre « chiffré » pour synonyme de « sécurisé »

Le chiffrement protège les données en transit. Il ne valide pas le point d’extrémité, ne limite pas l’accès, n’empêche pas la propagation latérale, ni l’exfiltration une fois que l’attaquant est dans le tunnel.

À faire : traitez le VPN comme un point d’entrée non fiable. Appliquez un routage au moindre privilège, des politiques par utilisateur, la segmentation et la journalisation. Supposons que les endpoints seront compromis.

2) Accès réseau plat : « les utilisateurs VPN peuvent tout atteindre »

C’est le multiplicateur classique d’incident. Si le VPN assigne une IP à l’intérieur de votre espace RFC1918 « de confiance » et que vos pare‑feux traitent cela comme interne, vous avez créé un LAN de bureau itinérant sans murs.

À faire : créez une plage/ un sous‑réseau VPN dédié, faites‑le transiter par un point d’application de politique et autorisez explicitement seulement ce qui est requis. Le refus par défaut vaut mieux que « on verrouillera plus tard ». « Plus tard » devient « après l’incident ».

3) Split tunneling activé par défaut sans contrôles compensatoires

Le split tunneling fait circuler les routes d’entreprise via le VPN, tandis que le trafic Internet sort directement du client. Cela peut être acceptable—si vous comprenez les conséquences : fuites DNS, interception de trafic et un appareil compromis faisant le pont entre les réseaux.

À faire : décidez intentionnellement. Si le split tunnel est nécessaire, verrouillez le DNS (résolveurs internes via le tunnel), imposez une politique de pare‑feu hôte et restreignez les routes internes annoncées. Pour les rôles à haut risque, désactivez le split tunneling.

4) Authentification faible : mots de passe seuls, comptes partagés, pas de MFA

Un VPN d’accès distant authentifié uniquement par mot de passe invite les attaques de credential stuffing. Les comptes partagés sont pires : pas de responsabilité, pas de révocation ciblée, et pas de piste d’audit propre.

À faire : exigez le MFA et privilégiez l’authentification par certificat/lié à l’appareil. Désactivez les comptes partagés. Si vous avez besoin d’un accès « break‑glass », créez des comptes limités dans le temps avec un routage strict et une surveillance renforcée.

5) Identifiants de longue durée et rotation de certificats négligée

Les certificats et clés statiques qui vivent pendant des années transforment une compromission d’identifiants en accès persistant multi‑années. La rotation semble opérationnelle jusqu’à ce que vous l’automatisiez ; alors elle devient un événement calendaire géré par un bot.

À faire : raccourcissez les durées de vie, automatisez le renouvellement et le déploiement, et construisez un scénario de révocation qui fonctionne réellement (CRL/OCSP si applicables ; pour WireGuard, faites tourner les clés et supprimez les pairs).

6) Exposer les interfaces de gestion à Internet

L’UI d’administration de votre passerelle VPN n’est pas une page de démonstration SaaS. Si elle est atteignable depuis Internet, elle sera scannée, brute‑forcée et martelée par des kits d’exploits. Ce n’est pas de la spéculation ; c’est un mardi.

À faire : placez la gestion derrière un réseau admin séparé ou un bastion, restreignez par adresse source, exigez le MFA et journalisez chaque action administrative. Mieux : pas d’UI web en prod pour les changements—utilisez la gestion de configuration et le contrôle de version.

7) Pas de journalisation significative (ou des logs inexploitables sous pression)

Les logs VPN ne sont pas optionnels. Sans eux, vous ne pouvez pas répondre aux questions basiques : qui s’est connecté, d’où, ce qu’il a accédé, et si les schémas d’accès ont changé avant l’incident. En IR, « nous n’avons pas ces données » est une phrase à effet limitant de carrière.

À faire : centralisez les logs, conservez une rétention suffisante pour couvrir votre fenêtre de détection et d’investigation, et indexez par nom d’utilisateur/appareil/IP. Journalisez les résultats d’auth, les IP assignées, les octets transférés et les changements de config.

8) Ignorer la posture des endpoints et la confiance des appareils

Les VPN authentifient souvent l’utilisateur mais pas l’appareil. Un mot de passe pêché sur un laptop non géré devient alors « un accès légitime ».

À faire : faites respecter la posture des appareils quand c’est possible : certificats d’appareils gérés, présence EDR, chiffrement disque, versions minimales d’OS, et révocation d’accès pour les endpoints non conformes. Si vous ne pouvez pas appliquer cela, réduisez les routes et les privilèges.

9) Mauvaise gestion du DNS : fuites, confusion split‑horizon et exposition de domaines internes

Les clients VPN qui continuent d’utiliser des résolveurs publics fuguent des domaines internes (utiles aux attaquants) et cassent des applications. Les clients qui utilisent le DNS interne pour tout peuvent créer des indisponibilités si le résolveur est inaccessible ou lent.

À faire : configurez le DNS explicitement. Utilisez les résolveurs internes via le tunnel, définissez les domaines de recherche intentionnellement, et surveillez la latence des résolveurs. Réfléchissez bien aux politiques DoT/DoH : elles peuvent contourner les contrôles DNS d’entreprise sauf si elles sont gérées.

10) Angles morts MTU/fragmentation qui ressemblent à des « pannes aléatoires »

L’encapsulation réduit le MTU effectif. Certains chemins bloquent les messages ICMP « fragmentation needed ». Résultat : certaines applications se figent, les paquets volumineux stagnent, et tout le monde blâme « le VPN instable ».

À faire : configurez le MSS clamping ou ajustez le MTU en fonction du surcoût d’encapsulation. Validez avec de vrais tests (pas seulement ping). Surveillez les retransmissions et les schémas de blackhole MTU.

11) « Optimisations de performance » qui suppriment les garde‑fous

Désactiver le rekeying parce que ça « provoque des coupures ». Désactiver le perfect forward secrecy pour économiser du CPU. Augmenter les timeouts de session pour réduire les invites de connexion. Tout cela est tentant, et tout cela vieillit mal.

À faire : optimisez avec mesure et préservez les propriétés de sécurité. Scalez les gateways, utilisez du crypto moderne, déchargez quand c’est pertinent, et ajustez les timeouts avec des modèles de menace—pas en fonction du niveau d’irritation.

12) Pas de segmentation et pas de contrôle d’egress une fois à l’intérieur

Même avec un inbound au moindre privilège, il faut encore un contrôle d’egress. Si un client VPN peut atteindre des ressources internes et exfiltrer librement vers Internet, vous avez construit une pompe à données.

À faire : restreignez l’accès aux réseaux sensibles, ajoutez un firewall par segment et surveillez l’egress. Pour les environnements très sensibles, forcez tout le trafic via une inspection et contrôlez les destinations sortantes.

Tâches pratiques avec commandes (sortie → décision)

Ce sont des tâches que vous pouvez exécuter aujourd’hui. Chacune inclut une commande réaliste, une sortie d’exemple, ce que cela signifie, et quelle décision en tirer. Supposons des serveurs Linux pour les points de terminaison VPN ; adaptez si nécessaire.

Task 1: Confirm the VPN service is listening (and on what address)

cr0x@server:~$ sudo ss -lntup | grep -E ':(1194|443|51820)\b'
udp   UNCONN 0      0            0.0.0.0:1194        0.0.0.0:*    users:(("openvpn",pid=1842,fd=6))
tcp   LISTEN 0      4096         0.0.0.0:443         0.0.0.0:*    users:(("nginx",pid=1021,fd=12))
udp   UNCONN 0      0            0.0.0.0:51820       0.0.0.0:*    users:(("wg-quick",pid=911,fd=3))

Ce que ça signifie : L’hôte écoute sur OpenVPN UDP/1194, HTTPS/443 (peut‑être pour un VPN TLS ou portail) et WireGuard UDP/51820.

Décision : Si le port attendu n’apparaît pas, arrêtez de déboguer les clients et corrigez le serveur/service. S’il est lié à 127.0.0.1 ou à une IP interne de façon inattendue, vous avez trouvé pourquoi les clients distants ne peuvent pas se connecter.

Task 2: Check firewall exposure of VPN and management ports

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 198.51.100.10/32 accept
    udp dport 51820 accept
    udp dport 1194 accept
    tcp dport 443 accept
    counter reject with icmpx type port-unreachable
  }
}

Ce que ça signifie : Drop par défaut, avec des exceptions. SSH est restreint à une IP ; les ports VPN sont ouverts au monde.

Décision : Les ports de gestion doivent être restreints ; les ports d’écoute VPN sont typiquement publics. Si vous voyez des ports d’UI admin (ou SSH) largement ouverts, corrigez‑les avant de discuter des suites de chiffrement.

Task 3: Detect brute-force or credential stuffing patterns in auth logs (OpenVPN example)

cr0x@server:~$ sudo awk '/AUTH_FAILED/ {print $NF}' /var/log/openvpn/server.log | sort | uniq -c | sort -nr | head
148 203.0.113.77
61  203.0.113.78
14  198.51.100.200

Ce que ça signifie : Les mêmes IPs génèrent un grand nombre d’échecs d’authentification.

Décision : Ajoutez du rate limiting, bloquez temporairement les IP abusives et vérifiez l’application du MFA. Passez aussi en revue si des noms d’utilisateur sont en cours d’énumération.

Task 4: Verify WireGuard peer activity and spot suspicious “always on” peers

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

peer: qk9Wb7q9j0p9xqv0t2h1V9kqk3rW8Z8l0y6H7m8b9cA=
  preshared key: (hidden)
  endpoint: 203.0.113.23:51122
  allowed ips: 10.44.0.10/32
  latest handshake: 12 seconds ago
  transfer: 18.34 GiB received, 92.10 GiB sent
  persistent keepalive: every 25 seconds

peer: NlG3b8pVj1kP0yXcVx3BzYt1d9v0m8a1q2w3e4r5t6Y=
  endpoint: (none)
  allowed ips: 10.44.0.11/32
  latest handshake: 9 days, 2 hours, 41 minutes ago
  transfer: 122.10 MiB received, 88.03 MiB sent

Ce que ça signifie : Un pair est activement connecté et transfère de gros volumes ; un autre ne s’est pas connecté depuis neuf jours.

Décision : Les transferts soutenus peuvent être normaux (sauvegardes) ou de l’exfiltration—corrélez avec l’identité utilisateur/appareil et le comportement attendu. Éliminez ou faites tourner les pairs obsolètes ; les identifiants « fantômes » sont un cadeau pour les attaquants.

Task 5: Confirm assigned VPN IPs and overlap with internal subnets (routing risk)

cr0x@server:~$ ip -4 addr show dev tun0
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    inet 10.8.0.1/24 scope global tun0
       valid_lft forever preferred_lft forever

Ce que ça signifie : Le pool VPN est 10.8.0.0/24. Si votre réseau interne utilise aussi 10.8.0.0/16 quelque part, vous allez rencontrer des collisions de routes et des problèmes de reachabilité « aléatoires ».

Décision : Choisissez un espace d’adresses non chevauchant et documentez‑le. Si vous chevauchez déjà, migrez : les collisions deviennent des bugs de sécurité et des pannes.

Task 6: Verify what routes are pushed to clients (OpenVPN server config)

cr0x@server:~$ sudo grep -E 'push "route|push "dhcp-option' /etc/openvpn/server.conf
push "route 10.20.0.0 255.255.0.0"
push "route 10.30.10.0 255.255.255.0"
push "dhcp-option DNS 10.20.0.53"
push "dhcp-option DOMAIN corp.example"

Ce que ça signifie : Les clients reçoivent l’instruction de router vers deux réseaux internes et d’utiliser un résolveur DNS interne ainsi qu’un domaine de recherche.

Décision : Assurez‑vous que ces routes représentent le moindre privilège, pas « tout l’interne ». Si vous voyez 0.0.0.0 poussé, c’est un tunnel complet—bon ou mauvais selon votre décision. Si le DNS n’est pas poussé, attendez‑vous à des fuites et à des résolutions internes cassées.

Task 7: Catch DNS leaks from a connected client (Linux client example)

cr0x@server:~$ resolvectl status | sed -n '1,120p'
Global
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 3 (wg0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53
        DNS Domain: corp.example

Link 2 (wlp2s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 8.8.8.8

Ce que ça signifie : L’interface VPN et l’interface Wi‑Fi ont chacune des résolveurs DNS. Selon l’ordre de résolution et le routage, certaines requêtes peuvent fuir vers le DNS public.

Décision : Configurez le client pour préférer le DNS VPN pour les domaines internes au minimum (split DNS), ou forcez le DNS VPN entièrement pour un tunnel complet. Testez avec des noms internes et surveillez où vont les requêtes.

Task 8: Validate MTU and detect blackhole fragmentation symptoms

cr0x@server:~$ ping -M do -s 1420 -c 3 10.30.10.25
PING 10.30.10.25 (10.30.10.25) 1420(1448) bytes of data.
1428 bytes from 10.30.10.25: icmp_seq=1 ttl=63 time=22.1 ms
1428 bytes from 10.30.10.25: icmp_seq=2 ttl=63 time=21.8 ms
1428 bytes from 10.30.10.25: icmp_seq=3 ttl=63 time=22.0 ms

--- 10.30.10.25 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Ce que ça signifie : Une charge utile de 1420 octets avec le bit DF fonctionne, ce qui suggère que le PMTU est au moins de 1448 octets au niveau ICMP (toujours pas la vérité TCP complète, mais un bon signal).

Décision : Si cela échoue à des tailles qui devraient marcher, implémentez le MSS clamping (iptables/nft) ou réduisez le MTU de l’interface. Considérez « certains sites chargent, d’autres se figent » comme un problème MTU jusqu’à preuve du contraire.

Task 9: Check TCP retransmits and drops on the VPN interface (performance clue)

cr0x@server:~$ ip -s link show dev wg0
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
    RX:  bytes packets errors dropped  missed   mcast
      9876543210  812345     0     213       0       0
    TX:  bytes packets errors dropped carrier collsns
      1234567890  543210     0     17       0       0

Ce que ça signifie : Il y a des pertes. Pas nécessairement catastrophique, mais si les pertes augmentent avec la charge, vous avez de la congestion, du queueing ou des soucis CPU.

Décision : Si les pertes sont non nulles et corrélées aux plaintes, étudiez les files NIC, la saturation CPU et les limites firewall/conntrack. Envisagez de répartir les gateways ou d’appliquer du QoS.

Task 10: Confirm system time and NTP sync (auth and certificate failures love clock drift)

cr0x@server:~$ timedatectl
               Local time: Sat 2025-12-27 10:14:05 UTC
           Universal time: Sat 2025-12-27 10:14:05 UTC
                 RTC time: Sat 2025-12-27 10:14:04
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Ce que ça signifie : NTP est actif mais l’horloge n’est pas encore synchronisée. Cela peut casser les handshakes TLS, les tokens MFA et la validation des certificats.

Décision : Corrigez la synchronisation temporelle immédiatement. Si votre IdP indique « token invalide » et que votre VPN dit « certificat pas encore valide », vérifiez l’heure avant tout le reste.

Task 11: Audit who can SSH to the VPN gateway (reduce blast radius)

cr0x@server:~$ sudo grep -E '^(AllowUsers|AllowGroups|PasswordAuthentication|PermitRootLogin)' /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
AllowGroups sre-vpn-admins

Ce que ça signifie : Le login root est désactivé, l’authentification par mot de passe est désactivée (bon), et seul un groupe spécifique peut SSH.

Décision : Maintenez la gestion serrée. Si l’authentification par mot de passe est activée, désactivez‑la sauf besoin très spécifique et contrôles compensatoires.

Task 12: Check for risky NAT rules that let VPN clients masquerade everywhere

cr0x@server:~$ sudo iptables -t nat -S | sed -n '1,80p'
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Ce que ça signifie : Les clients VPN (10.8.0.0/24) sont NATés sur eth0. Cela peut être prévu pour l’accès Internet—ou un chemin accidentel permettant à tout le monde d’exfiltrer.

Décision : Si vous autorisez la sortie Internet aux clients VPN, appliquez du filtrage egress et de la journalisation. Si ce n’est pas nécessaire, retirez le NAT et routez uniquement vers les destinations internes requises.

Task 13: Confirm IKEv2/IPsec status and failing negotiations (strongSwan example)

cr0x@server:~$ sudo ipsec statusall | sed -n '1,120p'
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.8.0):
  uptime: 2 hours, since Dec 27 08:10:31 2025
  worker threads: 10 of 16 idle, job queue: 0/0/0/0, scheduled: 3
Listening IP addresses:
  192.0.2.10
Connections:
  roadwarrior:  %any...192.0.2.10  IKEv2, dpddelay=30s
  roadwarrior:   local:  [vpn-gw] uses EAP
  roadwarrior:   remote: uses EAP
Security Associations (1 up, 0 connecting):
  roadwarrior[7]: ESTABLISHED 4 minutes ago, 203.0.113.55[alice]...192.0.2.10[vpn-gw]
  roadwarrior{9}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c3b2a1f2_i c4d3b2a1_o

Ce que ça signifie : Le démon est up, à l’écoute, et au moins une SA est établie. Si les utilisateurs ne peuvent pas se connecter, ce n’est pas une panne totale du service.

Décision : Si vous voyez beaucoup de connexions « connecting » et aucune établies, regardez les backends d’auth (RADIUS/IdP), un mismatch de propositions, ou des paquets UDP/500+4500 bloqués.

Task 14: Validate that VPN client traffic is constrained by firewall policy (example)

cr0x@server:~$ sudo nft list chain inet filter forward
table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iif "wg0" oif "lan0" ip daddr 10.30.10.25 tcp dport { 443, 22 } accept
    iif "wg0" oif "lan0" ip daddr 10.30.20.0/24 tcp dport 5432 accept
    counter reject with icmpx type admin-prohibited
  }
}

Ce que ça signifie : Le trafic de l’interface VPN n’est autorisé qu’à des destinations/ports spécifiques ; tout le reste est refusé.

Décision : Voilà à quoi ressemble un VPN « moindre privilège ». Si votre chaîne forward a une policy ACCEPT (ou que les règles sont trop larges), vous êtes à un laptop compromis d’une campagne de scan interne.

Erreurs courantes : symptômes → cause racine → correction

« Le VPN se connecte, mais rien d’interne ne charge »

Syndromes : Le client indique connecté ; les sites internes expirent ; parfois le ping marche, parfois non.

Cause racine : Routes manquantes (non poussées), masque de sous‑réseau erroné, drops sur la chaîne forward du pare‑feu, ou DNS pointant vers des résolveurs publics.

Correction : Confirmez le push de routes (config serveur), vérifiez la table de routage client, forcez le DNS via le tunnel et assurez que les règles forward autorisent explicitement les destinations requises.

« Seuls certains sites/apps bloquent via le VPN »

Syndromes : Slack fonctionne, certaines pages SaaS se figent, les upload de fichiers stagnent, RDP gèle, les gros téléchargements échouent.

Cause racine : Blackhole MTU dû à l’encapsulation et ICMP fragmentation‑needed bloqué ; MSS non clampé.

Correction : Réduisez le MTU sur l’interface VPN ou clampz le MSS TCP sur la passerelle. Testez avec des pings DF et de vraies sessions TCP.

« Les utilisateurs reçoivent des invites MFA répétées ou des boucles de réauth »

Syndromes : Les gens s’authentifient puis se font déconnecter ; les tokens sont « invalides » de manière intermittente.

Cause racine : Dérive d’horloge sur la passerelle ou problèmes d’intégration IdP ; timeouts de session trop agressifs ; callback SSO cassé à cause du DNS/egress.

Correction : Corrigez le NTP, vérifiez la synchronisation temporelle ; alignez les durées de session ; assurez‑vous que les endpoints IdP requis sont atteignables et non bloqués par les contrôles egress.

« Un utilisateur est lent, tout le monde est OK »

Syndromes : Plaintes isolées ; tests de vitesse très variables.

Cause racine : CPU/crypto de l’endpoint, problèmes Wi‑Fi, interférence portail captif, pare‑feu local, ou mismatch de résolveur DNS.

Correction : Faites‑lui tester sur un réseau filaire ou un autre ISP, comparez les réglages DNS, capturez les stats d’interface et vérifiez qu’il est sur le profil VPN attendu.

« Nous voyons des scans internes depuis une IP VPN »

Syndromes : Alertes IDS, scans de ports, tentatives d’auth contre de nombreux hôtes internes depuis une adresse du pool VPN.

Cause racine : Endpoint compromis avec accès réseau large ; absence de segmentation ; détection d’anomalies insuffisante ; identifiant obsolète non révoqué.

Correction : Isolez immédiatement cette identité VPN (désactivez le compte, révoquez certif/clé), restreignez les routes VPN, implémentez des politiques par‑utilisateur/groupe et ajoutez des alertes sur des comportements de scan depuis les pools VPN.

« Après une mise à jour de la passerelle, les clients ne peuvent plus se connecter »

Syndromes : Soudainement personne ne peut établir de tunnels ; les logs montrent des échecs de handshake ou un mismatch de proposition.

Cause racine : Changements de suite crypto, désactivation d’algorithmes legacy sans mise à jour client, ou dérive de gestion de config ayant changé l’écoute.

Correction : Faites des déploiements par étapes, gardez des fenêtres de compatibilité et testez avec des clients représentatifs. Traitez le VPN comme une API avec des comportements versionnés.

Trois mini‑récits du monde de l’entreprise

Mini‑récit n°1 : L’incident causé par une mauvaise hypothèse

Ils avaient un « VPN sécurisé » parce qu’il utilisait un chiffrement moderne et le MFA. La direction aimait cette phrase. Le pool VPN vivait à l’intérieur d’un large espace RFC1918 que la société utilisait déjà entre datacenters, agences et VPC cloud, parce que « c’est privé de toute façon ».

Quand l’ordinateur d’un sous‑traitant a été infecté, l’attaquant n’a pas eu besoin de casser le VPN. Il s’est authentifié normalement. Il disposait désormais d’une adresse qui ressemblait à une adresse interne. Les services internes faisaient confiance à ces IP sources parce qu’une décennie de règles de pare‑feu équivalait « IP privée » à « réseau employé ». Quelques panneaux d’administration legacy étaient accessibles. Quelques environnements dev avaient des identifiants partagés. Vous devinez la suite.

La première alerte est venue d’une équipe base de données constatant des tentatives de login étranges depuis un « sous‑réseau interne connu ». Personne ne l’a d’abord traité comme hostile. La seconde alerte fut une rafale de requêtes DNS internes pour des noms n’apparaissant que dans de vieux runbooks. C’est alors que l’SRE de garde a eu des doutes.

Le post‑mortem fut gênant parce que rien n’avait été « piraté » au sens hollywoodien. C’est l’hypothèse qui a fait le mal : « VPN = interne = confiance. » La correction fut tout aussi peu glamour : déplacer les clients VPN dans un sous‑réseau dédié, placer ce sous‑réseau derrière une politique explicite, et retirer la confiance basée sur l’IP des surfaces d’administration.

Ils ont aussi appris que « espace d’adresses privé » n’est pas une frontière de sécurité. C’est juste des mathématiques.

Mini‑récit n°2 : L’optimisation qui s’est retournée contre eux

Une autre entreprise avait des plaintes persistantes sur la vitesse du VPN. Le CPU de la passerelle montait en pointe, et le helpdesk était lassé d’entendre « mes appels vidéo saccadent ». Quelqu’un proposa d’activer le split tunneling par défaut pour garder le trafic Internet hors du VPN. Le changement réduisit immédiatement la charge de la passerelle. Les graphiques chutèrent et tout le monde sourit.

Deux mois plus tard, un ingénieur sécurité remarqua un schéma : des noms internes apparaissant dans les logs DNS publics de quelques endpoints. Pas la requête complète (merci aux subtilités du domaine de recherche), mais assez pour révéler des conventions de nommage internes. Pendant ce temps, un kit de phishing ciblait des utilisateurs distants sur le Wi‑Fi d’hôtels et servait une fausse page SSO. L’attaquant obtint des identifiants et un token de session actif.

Avec le split tunneling, le laptop compromis envoyait son trafic Internet hors de l’inspection et des contrôles egress d’entreprise. L’attaquant a utilisé la session navigateur pour accéder aux applis internes via les routes VPN tout en exfiltrant des données directement via la connexion Internet locale. C’était rapide, silencieux, et ça ne déclenchait pas les alarmes sortantes habituelles parce que l’exfiltration n’a jamais touché le réseau corporate.

L’optimisation a fonctionné. La posture sécurité non. Ils ont conservé le split tunneling, mais seulement après avoir mis en place un split DNS correct, resserré les routes, imposé la posture des endpoints et ajouté des règles de pare‑feu côté client pour bloquer le forwarding/bridging. Les graphiques de performance sont restés bons. Le risque n’était plus invisible.

Mini‑récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation gérait deux gateways VPN par région avec une config identique, poussée par la gestion de configuration. Chaque changement passait par une pull request, et chaque PR avait une checklist : ports, routes, méthodes d’auth, DNS, logging et plan de rollback. C’était aussi excitant qu’un tableur, et c’est un compliment.

Un vendredi, leur fournisseur d’identité eut une panne partielle affectant une partie des challenges MFA. Les utilisateurs ont commencé à réessayer en boucle, provoquant une vague d’échecs d’auth. Les gateways VPN restèrent up, mais les logs d’auth ressemblaient à une attaque : beaucoup d’échecs, beaucoup d’IP, haut volume. La plupart des organisations auraient réagi en bloquant agressivement des IP et empiré la panne.

Eux ne l’ont pas fait. Parce qu’ils avaient de bons logs, ils ont pu distinguer « échecs MFA légitimes d’utilisateurs connus » de « noms d’utilisateur invalides depuis des adresses aléatoires ». Ils avaient aussi des limites de débit qui ralentissaient les tentatives brute force sans pénaliser trop sévèrement les réessais normaux.

Plus important, ils disposaient d’une procédure break‑glass testée avec un chemin d’accès séparé et strictement limité pour les ingénieurs de garde. Ce chemin utilisait des certificats d’appareil et permettait l’accès seulement aux hôtes admin critiques. Le reste de l’entreprise a attendu que l’IdP revienne ; les personnes nécessaires pour réparer la prod pouvaient toujours accéder.

Blague n°2 : La seule chose moins glamour que la gestion de configuration est d’expliquer aux auditeurs pourquoi vous ne l’avez pas.

Checklists / plan étape par étape

Plan de durcissement étape par étape (faire dans cet ordre)

1. Définissez le modèle de menace. Accès distant pour employés ? Sous‑traitants ? Site‑à‑site ? Rôles à haut risque ? Si vous ne pouvez pas dire contre qui vous vous protégez, vous optimiserez pour l’ambiance.
2. Créez un sous‑réseau/plage VPN dédié. Faites‑le transiter par un point d’application de politique (firewall/security group) avec refus par défaut.
3. Mettez en œuvre le routage au moindre privilège. Poussez seulement les routes nécessaires. Utilisez des politiques par groupe (ingénierie vs finance vs fournisseurs).
4. Exigez MFA et auth liée à l’appareil. Privilégiez les certificats ou l’identité d’appareil gérée plus le MFA, pas seulement les mots de passe.
5. Verrouillez l’accès de gestion. Pas d’UI admin sur Internet public. Restreignez SSH et les API admin. Journalisez les actions admin.
6. Réglez correctement le DNS. Décidez tunnel complet vs split tunnel ; implémentez le split DNS si nécessaire ; empêchez les fuites ; surveillez les performances des résolveurs.
7. Gérez explicitement le MTU. Définissez MTU/MSS clamping selon l’encapsulation et validez par des tests.
8. Centralisez logs et alertes. Journalisez connexions, résultats d’auth, IP assignées, octets et changements de config. Alertez sur les anomalies depuis les pools VPN.
9. Construisez rotation et révocation. Faites tourner certificats/clés régulièrement ; assurez‑vous que le offboarding retire l’accès en quelques heures, pas en semaines.
10. Exécutez des exercices d’incident. Entraînez‑vous à « désactiver un utilisateur », « faire tourner une clé », « isoler un sous‑réseau » et « rollback de configuration » sous pression temporelle.

Checklist opérationnelle pour chaque changement VPN

• Ce changement étend‑il les réseaux ou ports accessibles depuis les pools VPN ?
• Active‑t‑on accidentellement le split tunneling ou le tunnel complet ?
• Changeons‑nous de suites crypto, d’intervalles de rekey ou de durées de session ?
• Cela brisera‑t‑il des clients anciens, et avons‑nous un plan de compatibilité ?
• Les logs continuent‑ils d’être générés et transférés après le changement ?
• Avons‑nous un chemin de rollback qui ne nécessite pas que le VPN fonctionne ?

Checklist d’offboarding (les accès que vous oubliez sont ceux qui sont abusés)

• Désactiver le compte d’identité (IdP) et révoquer les sessions.
• Révoquer le certificat/identité d’appareil ou supprimer le pair WireGuard.
• Invalider les tokens API utilisés par les clients VPN (si applicable).
• Retirer des groupes d’autorisation VPN et relancer le déploiement des politiques.
• Rechercher dans les logs l’activité VPN récente et signaler les anomalies.

FAQ

Un VPN vaut‑il encore la peine si nous passons au « zero trust » ?

Oui, mais traitez‑le comme une méthode d’accès, pas comme une attribution de confiance. Un VPN peut être un transport. Le zero trust est le modèle de politique au‑dessus : moindre privilège, vérification continue, segmentation et identité forte.

Faut‑il désactiver le split tunneling ?

Pour les rôles à haut risque et les environnements sensibles, oui par défaut. Pour un usage corporate général, le split tunneling peut être acceptable si vous implémentez le split DNS, des contrôles endpoint et un découpage strict des routes internes.

Quelle est la plus grosse amélioration de sécurité VPN ?

Ne plus donner un accès réseau large aux clients VPN. Placez‑les dans un sous‑réseau dédié et autorisez seulement ce qui est nécessaire. Cette décision réduit considérablement le rayon d’impact en cas d’incident.

Les appliances VPN sont‑elles intrinsèquement moins sûres que l’auto‑hébergement ?

Non. Les appliances échouent quand elles ne sont pas patchées, trop exposées, ou mal surveillées—comme l’auto‑hébergement. La différence tient au contrôle opérationnel : vous avez besoin d’un pipeline de patch fiable, de visibilité et d’un rollback dans les deux cas.

Comment détecter des identifiants VPN compromis ?

Cherchez les anomalies : nouvelles géographies, heures de connexion inhabituelles, volumes élevés d’échecs d’auth suivis d’un succès, pics de transfert inattendus, et scans internes depuis les pools VPN.

Faut‑il capturer tout le trafic au niveau paquet sur la passerelle VPN ?

Pas toujours, et c’est coûteux et sensible. Commencez par de solides logs de connexion/auth et des logs de flux. Utilisez la capture ciblée pour les investigations et le débogage MTU/performance.

L’espace IP « privé » est‑il sûr à faire confiance ?

Non. L’espace IP privé n’est pas une propriété de sécurité. La confiance doit venir de l’identité authentifiée, de la posture de l’appareil et d’une politique explicite—pas d’une adresse qui commence par 10.

Qu’en est‑il du VPN toujours‑actif pour les laptops gérés ?

Le toujours‑actif peut être excellent : application cohérente des politiques et moins de risques « j’ai oublié de me connecter ». Mais cela augmente les enjeux de disponibilité : si le VPN tombe, votre workforce tombe. Construisez de la redondance et testez les modes de panne.

À quelle fréquence devons‑nous faire tourner certificats/clés VPN ?

Autant que vous pouvez soutenir opérationnellement avec automatisation. Beaucoup d’organisations visent des mois plutôt que des années. Faites aussi une rotation immédiate en cas de suspicion de compromission et lors de changements de personnel importants pour des endpoints partagés.

Pouvons‑nous compter uniquement sur le MFA ?

Non. Le MFA réduit l’impact du vol d’identifiants, mais n’empêche pas les endpoints compromis, les réseaux mal routés, les accès trop larges ou l’exfiltration de données. Le MFA est une ceinture de sécurité, pas une cage de protection.

Conclusion : prochaines étapes qui réduisent vraiment le risque

Les incidents VPN ne viennent rarement d’un mathématique cassée. Ils proviennent de la surconfiance, de la portée excessive et du sous‑journal. Votre tunnel peut être parfaitement chiffré et rester une voie d’accès à grande vitesse pour les attaquants si vous le traitez comme une cape magique.

Faites ceci ensuite, dans cet ordre :

1. Placez les clients VPN dans un sous‑réseau dédié et appliquez un forward par défaut‑deny.
2. Réduisez les routes au moindre privilège (par groupe) et resserrez volontairement le comportement DNS.
3. Exigez MFA plus auth liée à l’appareil, et automatisez rotation/révocation.
4. Retirez l’exposition Internet des surfaces de gestion ; imposez la journalisation admin.
5. Implémentez le playbook de diagnostic rapide comme runbook d’astreinte, avec les commandes ci‑dessus pré‑approuvées.

Si vous ne faites rien d’autre : arrêtez de traiter le VPN comme « interne ». C’est de l’extérieur avec un meilleur chiffrement. Concevez en conséquence.