Contrôle d’accès VPN bureau : autoriser uniquement ce qui est nécessaire (pas de LAN-à-LAN complet)

Le principe : le VPN n’est pas un téléporteur vers votre LAN

Le terme « VPN de bureau » tend à être perçu comme un câble magique : branchez un portable distant dessus et—pouf—il est « au bureau ».
C’est le modèle mental qui crée l’accès LAN-à-LAN complet, des routes larges et des règles de pare-feu « any-any ».
C’est aussi le modèle mental qui rend la réponse aux incidents insupportable.

Un VPN n’est qu’un transport. Ce n’est pas un système d’autorisation. Si vous n’empilez pas délibérément de l’autorisation au-dessus—routes,
politiques de pare-feu et portes dépendantes de l’identité—vous accordez ce que la topologie réseau permet aujourd’hui.
Et la topologie change tout le temps.

Le bon modèle est : un VPN est une rampe d’accès contrôlée vers un petit ensemble de services. Ces services peuvent être sur votre LAN,
dans une DMZ/segment VPN ou dans des réseaux cloud. Mais la rampe d’accès ne doit pas conduire à « tout ce qui a une adresse RFC1918 ».

Conseil d’opinion : considérez le « LAN-à-LAN complet » comme une violation du principe du refus par défaut. Si vous en avez besoin, vous devez pouvoir le justifier par écrit.
Pas en réunion de comité. Dans un compte rendu post-incident.

Modèle de menace en langage clair : ce que vous défendez

1) Mouvement latéral à partir d’un endpoint compromis

Les endpoints distants sont désordonnés. Ils voyagent. Ils se connectent à des Wi‑Fi de café. Ils exécutent des extensions de navigateur « gratuites » pour une raison.
Si un endpoint est compromis et que votre VPN le place sur la même portée L2/L3 que les serveurs de fichiers, imprimantes, hyperviseurs, sauvegardes,
et consoles d’administration « temporaires », vous venez d’offrir à un attaquant une autoroute privée.

2) Accès accidentel : l’erreur honnête qui fait quand même des dégâts

La plupart des « accès non autorisés » dans les réseaux d’entreprise ne sont pas un méchant à capuche.
C’est un développeur qui pointe un script vers 10.0.0.0/8 parce que c’était plus rapide que de trouver la bonne IP.
C’est un fournisseur « qui vérifie juste quelque chose » sur un hôte auquel il n’était pas censé accéder.
Une conception VPN à moindre privilège prévient à la fois la malveillance et les erreurs.

3) Fuites de routes et sous-réseaux qui se chevauchent

Si vous avez déjà fusionné deux entreprises ou ajouté un nouveau VPC cloud, vous avez rencontré le méchant :
les espaces RFC1918 qui se chevauchent. Avec des routes VPN larges, il devient ambigu quel « 10.0.12.0/24 » vous vouliez,
et le mauvais chemin fonctionne parfois—jusqu’à ce qu’il cesse, et que vous passiez votre week-end à diff des tables de routage.

4) DNS comme vecteur d’accès

Le DNS privé peut révéler des noms internes, des cibles de découverte de services et des points de gestion « cachés ».
Vous ne voulez pas que chaque utilisateur VPN interroge chaque zone interne, même s’il ne peut pas se connecter ensuite.
La reconnaissance est une phase, pas une permission.

5) Défaillance opérationnelle : le modèle d’accès que vous ne pouvez pas déboguer

Une politique VPN trop astucieuse est une menace en soi. Si la seule personne qui comprend le routage est en vacances,
votre temps moyen de réparation devient « quand elle rentre ». La débogabilité est une caractéristique de sécurité.

Idée paraphrasée (attribuée) : « L’espoir n’est pas une stratégie. » — souvent citée dans la culture ops attribuée au General Gordon R. Sullivan.
Que vous aimiez la formulation ou non, cela s’applique : ne « comptez pas » sur le maintien de la sécurité d’un accès VPN large.

Contexte historique et faits intéressants (parce qu’on les réapprend)

1. Les VPN sont devenus courants comme « extensions de périmètre » dans les années 1990/début 2000, quand les bureaux avaient une frontière intérieur/extérieur claire et que l’accès distant était rare.
2. IPsec a été conçu pour la sécurité réseau-à-réseau, pas pour l’accès par application—donc la « connectivité de sous-réseau complète » est un résultat naturel (mais dépassé).
3. Le split tunneling était autrefois traité comme une hérésie car il brise l’histoire « tout passe par le siège » pour inspection ; aujourd’hui il est souvent nécessaire pour la performance et la réalité SaaS.
4. Le NAT a rendu les fusions plus difficiles : les réseaux RFC1918 chevauchants étaient tolérés parce que le NAT « réglait le problème », jusqu’à ce que vous essayiez de joindre deux environnements NAT-heavy via VPN et que tout entre en collision.
5. Les premiers accès distants concentraient la confiance dans la passerelle VPN ; les designs modernes distribuent la confiance vers les fournisseurs d’identité, les contrôles de posture de l’appareil et les proxies applicatifs.
6. Les « réseaux plats » étaient autrefois normaux parce que les menaces internes étaient sous-modélisées ; le ransomware et le vol d’identifiants ont rendu la segmentation interne non négociable.
7. WireGuard a popularisé la route-comme-politique : son réglage AllowedIPs est à la fois routage et contrôle d’accès, ce qui est élégant et facile à se tirer une balle dans le pied.
8. Le split-horizon DNS n’est pas nouveau, mais les VPN l’ont rendu omniprésent : les noms internes pour services internes sont devenus une dépendance, et un DNS mal cadré est devenu une fuite courante.
9. Le réseau cloud a poussé la pensée « service d’abord » : les security groups et gateways L7 ont forcé les équipes à nommer ce à quoi elles se connectent, pas seulement quel sous-réseau existe.

Si vous ne retenez qu’une leçon de l’histoire : les architectures survivent souvent aux raisons pour lesquelles elles ont été construites. Le VPN que vous avez hérité était probablement raisonnable autrefois.
Il n’est simplement plus raisonnable aujourd’hui.

Architectures de référence qui évitent le LAN-à-LAN complet

Architecture A : « VPN vers un segment de services », pas VPN vers tout le LAN

Placez le terminateur VPN (WireGuard, OpenVPN, passerelle IPsec) dans un sous-réseau/VLAN VPN dédié.
De là, autorisez uniquement l’egress vers les services requis : bastion pour tickets, Git, CI, une poignée d’API internes, peut-être RDP/SSH vers un bastion.
Refusez tout le reste par défaut.

Point clé : le sous-réseau VPN est un réseau client, pas un LAN pair. Ne routez pas les utilisateurs distants directement dans le « corp-lan ».
Routez-les vers « vpn-clients », puis appliquez un pare-feu vers des destinations spécifiques.

Architecture B : Accès par application via bastions et proxies (ennuyeux, efficace)

Si les utilisateurs ont besoin d’un accès d’administration, ils n’ont pas besoin de tout le réseau admin. Ils ont besoin d’un jump host avec MFA, journalisation et une courte liste de cibles autorisées en sortie.
Les bastions SSH, les passerelles RDP et les reverse proxies HTTP sont des technologies anciennes. C’est pour ça qu’elles fonctionnent.

Le VPN devient une méthode d’accès à un point de contrôle (bastion/proxy), pas une route globale vers tout.
Une fois que vous acceptez cela, votre politique de pare-feu devient plus petite et vos audits plus simples.

Architecture C : Accès conscient de l’identité (quand c’est possible)

Si vos services internes peuvent se trouver derrière un modèle de proxy conscient de l’identité (IAP), faites-le. Cela réduit la confiance au niveau réseau et déplace l’autorisation vers l’identité de l’utilisateur et de l’appareil.
Mais ne vous mentez pas : ce n’est pas « régler et oublier ». Vous avez toujours besoin de segmentation réseau pour contenir ce qui arrive quand l’identité est contournée ou mal configurée.

Architecture D : Vrai site-à-site, mais fortement limité et documenté

Parfois, vous avez vraiment besoin d’une connectivité site-à-site : imprimantes d’agence, contrôleurs industriels ou systèmes legacy qui ne peuvent pas passer par des proxies.
Très bien. Mais vous n’avez toujours pas besoin de « n’importe quel sous-réseau vers n’importe quel sous-réseau ».
Notez précisément les préfixes qui doivent être atteignables et faites appliquer cela à la fois dans le routage et les couches de pare-feu.

Blague #1 : Un « VPN full-tunnel any-any temporaire » est comme un « mot de passe admin de production temporaire ». Il existe pour toujours, et il devient dangereux.

Contrôles qui fonctionnent vraiment : routage, pare-feu, identité, DNS

1) Routage : choisissez des préfixes explicites, pas « tout ce qui est privé »

Le mode d’échec le plus courant est d’annoncer de larges plages internes aux clients VPN parce que c’est pratique :
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. N’en faites pas.
Ce n’est pas du routage ; c’est de l’abdication.

Faites plutôt ceci :

• Annoncer uniquement les sous-réseaux de service requis (ou mieux, les IP de service).
• Gardez la liste courte ; si elle grossit, vous avez un problème d’architecture, pas de routage.
• Pour WireGuard, utilisez AllowedIPs comme liste blanche stricte.
• Pour OpenVPN, poussez seulement les routes que vous souhaitez (push "route ..."), et bloquez client-à-client par défaut sauf si nécessaire.

2) Pare-feu : refus par défaut, puis autoriser par destination et port

Le routage décide de ce qui est atteignable. Le pare-feu décide de ce qui est autorisé. Vous avez besoin des deux parce que les routes ont tendance à changer,
et parce que « atteignable » est un ensemble bien plus large que « doit être utilisé ».

Le schéma de base :

• Définissez une plage source pour les clients VPN (par ex., 10.250.0.0/24).
• Permettez à cette source d’atteindre uniquement des destinations/ports spécifiques.
• Consignez les refus (sélectivement ; ne DDoS pas votre pipeline de logs).
• Bloquez l’est-ouest à l’intérieur du pool VPN sauf si vous supportez délibérément le trafic pair-à-pair.

3) Identité et posture d’appareil : le VPN doit savoir qui se connecte

Les règles basées sur IP seules sont fragiles. Liezz l’accès à l’identité quand c’est possible :

• Certificats par utilisateur (OpenVPN), clés WireGuard par utilisateur mappées à des comptes, ou solutions VPN intégrées à SSO.
• Des identifiants à courte durée de vie si vos outils le supportent.
• Des contrôles de posture d’appareil (appareil géré, chiffrement du disque, version OS) si votre environnement peut les appliquer.

Même si vous ne pouvez pas faire du « zero trust » bout en bout, vous pouvez au moins savoir à quel utilisateur appartient une clé,
et la révoquer sans envoyer un e‑mail à toute l’entreprise.

4) DNS : split-horizon avec un scalpel, pas une pelle

Les clients VPN ont souvent besoin du DNS interne pour un sous-ensemble de zones. Donnez-leur ces zones, pas tout votre espace de noms d’entreprise.
Si votre solution VPN peut faire un forwarding conditionnel (envoyer seulement corp.example vers les résolveurs internes), utilisez-le.
Sinon, soyez prudent : pousser des serveurs DNS internes aux clients peut involontairement router toutes les requêtes DNS via le VPN et créer des problèmes de confidentialité, performance et de débogage.

5) Observabilité : consignez ce qui compte et rendez-le interrogeable

Vous devez répondre, rapidement :

• Qui s’est connecté ? Depuis où ? Avec quel appareil/clé ?
• Quelles routes ont été assignées ?
• Qu’est-ce qui a été autorisé/refusé au pare-feu ?
• Quelles requêtes DNS ont été faites (au moins pour les zones internes) ?

Si votre réponse est « on peut probablement greper le serveur VPN », vous êtes à un incident d’apprendre la définition du « probablement ».

Tâches pratiques (commandes, sorties, décisions)

Ce sont les actions quotidiennes qui empêchent le « VPN moindre privilège » de rester un diaporama.
Chaque tâche inclut : une commande, ce que signifie une sortie typique, et la décision que vous prenez.
Les exemples supposent des passerelles VPN basées sur Linux et des outils courants.

Tâche 1 : Confirmer quelles routes le serveur VPN annonce réellement

cr0x@server:~$ sudo ip route show
default via 203.0.113.1 dev eth0 proto static
10.0.10.0/24 dev lan0 proto kernel scope link src 10.0.10.1
10.250.0.0/24 dev wg0 proto kernel scope link src 10.250.0.1
172.16.50.0/24 via 10.0.10.2 dev lan0 proto static

Ce que cela signifie : Le serveur a le LAN local 10.0.10.0/24, le pool VPN 10.250.0.0/24, et un sous-réseau routé 172.16.50.0/24.
Il s’agit du routage côté serveur, pas des routes « poussées » côté client, mais cela indique ce que vous pourriez activer.

Décision : Si vous voyez des routes larges (comme 10.0.0.0/8) sur la passerelle, arrêtez-vous et justifiez-les.
Resserrez pour ne permettre que les sous-réseaux qui hébergent les services que vous comptez exposer.

Tâche 2 : Pour WireGuard, lister les pairs et leurs AllowedIPs (votre politique d’accès réelle)

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

peer: M4x9Vt2g9bBv7hPpP3c0...
  preshared key: (hidden)
  endpoint: 198.51.100.24:53321
  allowed ips: 10.250.0.10/32, 10.0.30.15/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 128.21 MiB received, 44.02 MiB sent

peer: Q7u1kL0pZz2nWc3aY1r5...
  endpoint: 203.0.113.77:59610
  allowed ips: 10.250.0.11/32, 10.0.40.0/24
  latest handshake: 2 hours, 4 minutes ago
  transfer: 2.10 MiB received, 1.54 MiB sent

Ce que cela signifie : Le pair 1 peut router vers un hôte interne unique 10.0.30.15.
Le pair 2 peut router vers un sous-réseau entier 10.0.40.0/24. C’est une différence de politique qu’il faut documenter.

Décision : Préférez des routes hôtes ou des sous-réseaux de service serrés. L’accès à un sous-réseau doit nécessiter un propriétaire explicite et une raison.
Si vous ne pouvez pas nommer la raison, supprimez le sous-réseau.

Tâche 3 : Vérifier si le forwarding IP est activé (et s’il doit l’être)

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

Ce que cela signifie : L’hôte routera les paquets entre interfaces. C’est nécessaire pour de nombreux designs de passerelle VPN.
C’est aussi l’interrupteur qui transforme un « serveur VPN » en « routeur vers tout ».

Décision : Si vous utilisez un accès par proxy/bastion par application et n’avez pas besoin de routage L3, mettez-le à 0.
Si vous avez besoin de routage, compensez par des règles de pare-feu strictes sur le chemin de forwarding.

Tâche 4 : Inspecter la politique nftables pour assurer un refus par défaut sur le forwarding depuis le VPN

cr0x@server:~$ sudo nft list ruleset
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    tcp dport { 22, 51820 } accept
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iif "wg0" oif "lan0" ip daddr 10.0.30.15 tcp dport 443 accept
    iif "wg0" oif "lan0" ip daddr 10.0.40.0/24 tcp dport 5432 accept
  }

  chain output {
    type filter hook output priority 0; policy accept;
  }
}

Ce que cela signifie : Le forwarding est en drop par défaut. Deux autorisations explicites existent : HTTPS vers un hôte, et Postgres vers un sous-réseau.
C’est la forme souhaitée : exceptions étroites, règles lisibles.

Décision : Si votre chaîne forward a la politique accept, vous faites du « LAN-à-LAN complet » par accident.
Passez en drop et énumérez ce qui doit être atteignable.

Tâche 5 : Identifier ce que les clients VPN tentent (et échouent) d’atteindre

cr0x@server:~$ sudo nft add rule inet filter forward iif "wg0" counter log prefix "VPN-FWD-DROP " level info drop
cr0x@server:~$ sudo journalctl -n 5 -k
Aug 14 10:21:19 gw kernel: VPN-FWD-DROP IN=wg0 OUT=lan0 SRC=10.250.0.11 DST=10.0.10.25 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=51234 DPT=445 WINDOW=64240 SYN
Aug 14 10:21:20 gw kernel: VPN-FWD-DROP IN=wg0 OUT=lan0 SRC=10.250.0.11 DST=10.0.10.53 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=55911 DPT=53

Ce que cela signifie : Un client a tenté SMB (445) vers 10.0.10.25 et DNS vers 10.0.10.53, et les deux ont été bloqués.
C’est soit un accès non autorisé (bien), soit une règle manquante (aussi bien à découvrir tôt).

Décision : Décidez si ces destinations sont un besoin métier légitime. Sinon, continuez à les bloquer et envisagez de les restreindre aussi côté client.
Si oui, ajoutez une autorisation serrée : serveur spécifique, port spécifique, journalisé.

Tâche 6 : Vérifier le comportement NAT (le NAT peut cacher des problèmes, et parfois en créer)

cr0x@server:~$ sudo nft list table ip nat
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oif "lan0" ip saddr 10.250.0.0/24 masquerade
  }
}

Ce que cela signifie : Le trafic des clients VPN vers le LAN est masqueradé. Les hôtes LAN verront l’IP de la passerelle, pas l’IP du client.
Cela peut simplifier le routage côté LAN mais détruit l’attribution par client à la destination.

Décision : Évitez le NAT pour les environnements sensibles à l’audit/admin. Préférez des pools routés avec des routes de retour explicites afin que les logs montrent les vraies IP clients.
Si vous devez NATer (contraintes legacy), compensez par la journalisation côté passerelle et un mappage utilisateur détaillé.

Tâche 7 : Vérifier les fuites de routes vers les clients (exemple OpenVPN via status)

cr0x@server:~$ sudo tail -n 12 /var/log/openvpn/status.log
OpenVPN CLIENT LIST
Updated,2025-08-14 10:20:10
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
alice,198.51.100.24:53321,134507892,46158212,2025-08-14 08:12:03

ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.250.0.10,alice,198.51.100.24:53321,2025-08-14 10:20:09
GLOBAL STATS
Max bcast/mcast queue length,0
END

Ce que cela signifie : Vous pouvez voir quel utilisateur a quelle IP VPN. C’est le minimum nécessaire pour la corrélation en réponse aux incidents.

Décision : Si vous ne pouvez pas mapper les utilisateurs aux IP VPN de façon fiable, corrigez cela avant d’« optimiser » autre chose.
Le contrôle d’accès sans attribution est un tour de confiance.

Tâche 8 : Confirmer la configuration DNS sur le chemin client (quel résolveur est utilisé)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

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

Ce que cela signifie : Seul corp.example est routé vers le DNS interne, via le lien wg0.
C’est un façonnage DNS conditionnel ; cela évite de détourner toutes les requêtes DNS vers le bureau.

Décision : Si vous voyez le DNS interne défini globalement sans portage de domaine, attendez-vous à des bizarreries : connexions SaaS qui échouent, portails captifs brisés, et latence difficile à diagnostiquer.
Corrigez le façonnage avant que les utilisateurs ne « résolvent » le problème eux-mêmes en codant en dur des résolveurs publics.

Tâche 9 : Prouver atteignabilité vs permission (ping OK, TCP non)

cr0x@server:~$ ping -c 2 10.0.30.15
PING 10.0.30.15 (10.0.30.15) 56(84) bytes of data.
64 bytes from 10.0.30.15: icmp_seq=1 ttl=63 time=3.21 ms
64 bytes from 10.0.30.15: icmp_seq=2 ttl=63 time=3.08 ms

--- 10.0.30.15 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

cr0x@server:~$ nc -vz 10.0.30.15 443
Connection to 10.0.30.15 443 port [tcp/https] succeeded!

Ce que cela signifie : ICMP et TCP/443 sont autorisés, donc le service est atteignable et permis.
Si ping fonctionne mais que TCP échoue, vous avez probablement un problème de pare-feu/SG/politique applicative. Si ping échoue mais que TCP fonctionne, quelqu’un filtre ICMP (acceptable, mais soyez cohérents).

Décision : Utilisez ICMP seulement comme signal grossier. Prenez des décisions basées sur le port applicatif réel.

Tâche 10 : Identifier quel côté abandonne les paquets avec tcpdump

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.0.30.15 and tcp port 443 -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:24:10.102345 IP 10.250.0.10.51522 > 10.0.30.15.443: Flags [S], seq 1987654321, win 64240, options [mss 1360,sackOK,TS val 123 ecr 0,nop,wscale 7], length 0
10:24:11.110221 IP 10.250.0.10.51522 > 10.0.30.15.443: Flags [S], seq 1987654321, win 64240, options [mss 1360,sackOK,TS val 1123 ecr 0,nop,wscale 7], length 0
10:24:13.126019 IP 10.250.0.10.51522 > 10.0.30.15.443: Flags [S], seq 1987654321, win 64240, options [mss 1360,sackOK,TS val 3123 ecr 0,nop,wscale 7], length 0

Ce que cela signifie : Des SYN arrivent sur wg0, mais aucun SYN-ACK n’est vu en retour (au moins sur wg0).
Soit le forwarding/pare-feu bloque, soit le routage de retour est cassé, ou la destination est down/refuse.

Décision : Capturez sur les deux interfaces (wg0 et lan0). Si ça sort de lan0 mais qu’aucune réponse ne revient, c’est le chemin de retour ou le pare-feu côté destination.
Si ça ne quitte jamais lan0, c’est votre pare-feu/forwarding de passerelle.

Tâche 11 : Vérifier les sous-réseaux qui se chevauchent et les « routes d’ombre »

cr0x@server:~$ ip route get 10.0.40.10
10.0.40.10 via 10.0.10.2 dev lan0 src 10.0.10.1 uid 0
    cache

Ce que cela signifie : Le trafic vers 10.0.40.10 passe via 10.0.10.2. Si vous vous attendiez à ce qu’il soit local ou via un autre routeur, vous avez un décalage de route.

Décision : Si un préfixe peut être atteint via plusieurs chemins, rendez-le explicite et documentez le choix.
En conception VPN, l’ambiguïté est synonyme d’indisponibilité.

Tâche 12 : Valider le MTU et détecter les problèmes de fragmentation

cr0x@server:~$ ip link show wg0
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

cr0x@server:~$ ping -M do -s 1380 -c 2 10.0.30.15
PING 10.0.30.15 (10.0.30.15) 1380(1408) bytes of data.
1388 bytes from 10.0.30.15: icmp_seq=1 ttl=63 time=3.45 ms
1388 bytes from 10.0.30.15: icmp_seq=2 ttl=63 time=3.39 ms

--- 10.0.30.15 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Ce que cela signifie : Le MTU sur wg0 est 1420. Une charge utile de 1380 octets avec DF fonctionne ; vous ne verrez probablement pas de problèmes PMTUD pour le trafic typique.
Si cela échoue, de grands paquets TLS peuvent bloquer, et les utilisateurs rapporteront « ça se connecte mais ça se bloque aléatoirement. »

Décision : Si vous observez des trous MTU, définissez un MTU VPN plus bas et clampers MSS TCP sur la passerelle.
Ne « corrigez » pas en autorisant l’accès complet au LAN ; ce n’est pas une correction, c’est une reddition.

Tâche 13 : Confirmer que le trafic client-à-client est bloqué (prévenir le mouvement latéral entre pairs)

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.0.30.15 tcp dport 443 accept
    iif "wg0" oif "lan0" ip daddr 10.0.40.0/24 tcp dport 5432 accept
  }
}

Ce que cela signifie : Il n’y a pas de règle permettant iif wg0 vers oif wg0. Les clients VPN ne peuvent pas se parler via la passerelle.
C’est bien : un portable compromis ne peut pas scanner facilement le reste du pool VPN.

Décision : Autorisez le trafic pair-à-pair uniquement si vous avez un besoin produit clair (ex. outils de pair programming à distance) et une histoire de confinement.

Tâche 14 : S’assurer que la journalisation montre l’identité, pas seulement les IP (santé du mapping WireGuard)

cr0x@server:~$ sudo grep -R "M4x9Vt2g9bBv7hPpP3c0" -n /etc/wireguard/
 /etc/wireguard/wg0.conf:18:PublicKey = M4x9Vt2g9bBv7hPpP3c0...
 /etc/wireguard/wg0.conf:19:# owner=alice purpose=vendor-api access=10.0.30.15:443

Ce que cela signifie : La clé du pair est annotée avec la propriété et l’objectif. Ce n’est pas sophistiqué. C’est inestimable opérationnellement.

Décision : Si les pairs sont des blobs anonymes, vous hésiterez à révoquer l’accès parce que vous ne saurez pas qui casse quelque chose.
Ajoutez des métadonnées de propriété et rendez-les obligatoires pour les changements.

Blague #2 : La façon la plus rapide d’apprendre le réseau est d’autoriser 10.0.0.0/8 sur le VPN et d’attendre votre premier incident.
La deuxième plus rapide est de ne pas le faire.

Playbook de diagnostic rapide

Quand l’accès VPN est « lent », « cassé », ou « marche pour certains utilisateurs », ne commencez pas par réécrire les configs.
Commencez par trouver la couche qui échoue : transport, routage, pare-feu, DNS ou l’application.
Voici l’ordre qui raccourcit votre temps de vérité.

Premier : le tunnel est-il up et stable ?

• Vérifiez l’état handshake/connecté (wg show / statut OpenVPN / état SA IPsec).
• Recherchez des reconnexions fréquentes (généralement timeouts NAT, endpoints en mouvement ou problèmes MTU).
• Confirmez que le client a obtenu l’IP VPN attendue.

Second : la route est-elle correcte pour la destination spécifique ?

• Depuis le client : vérifiez que la route vers l’IP du service utilise l’interface VPN.
• Depuis la passerelle : ip route get <dest> et assurez-vous qu’elle pointe où vous pensez.
• Surveillez les sous-réseaux qui se chevauchent et les routes plus spécifiques accidentelles.

Troisième : le pare-feu autorise-t-il le tuple exact (src, dst, proto, port) ?

• Sur la passerelle : vérifiez les règles forward et les compteurs.
• Ajoutez temporairement une règle de drop journalisée pour voir ce qui est tenté.
• Confirmez que le pare-feu côté destination/groupes de sécurité autorisent aussi le pool VPN.

Quatrième : DNS et routage basé sur le nom

• Résolvez le nom du service depuis le client et confirmez qu’il retourne l’IP prévue (interne vs externe split).
• Confirmez que seules les zones internes requises sont routées vers les résolveurs internes.
• Si les utilisateurs rapportent « certains sites cassent », suspectez un hijack DNS full-tunnel ou des timeouts DNS via le VPN.

Cinquième : MTU et « ça time out seulement sur de grosses réponses »

• Faites des pings DF pour trouver une taille de charge sûre.
• Clampez MSS si nécessaire.
• Les symptômes ressemblent souvent à « la page de connexion charge, puis tourne indéfiniment ».

Sixième : application et authentification

• Une fois transport/routage/pare-feu/DNS corrects, déboguez le service lui-même (TLS, auth, logs applicatifs).
• Ne blâmez pas le VPN pour un 401. Il est innocent jusqu’à preuve du contraire.

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

Incident causé par une mauvaise hypothèse : « C’est seulement le sous-réseau dev »

Une entreprise de taille moyenne a déployé un WireGuard VPN pour des contractuels travaillant sur une migration. L’ingénieur réseau a fait la chose « raisonnable » :
ajouter 10.20.0.0/16 à AllowedIPs parce que c’était « l’environnement dev ».
Tout le monde pouvait atteindre le cluster dev et l’hôte Git interne. Les tickets se sont tûs.

L’hypothèse était que 10.20.0.0/16 était exclusivement dev. Ça l’était. Puis quelqu’un a ajouté quelques points d’administration « temporaires » dans cette plage :
une console de virtualisation, une UI de sauvegarde et une vieille boîte de monitoring qui avait encore des comptes locaux.
Personne n’a mis à jour la politique VPN parce que personne ne se souvenait que la politique VPN existait en tant que politique.

Le portable d’un contractuel a été infecté via une faille de navigateur. L’attaquant n’a pas eu besoin de « casser le VPN ».
Il a simplement utilisé le tunnel établi du contractuel et scanné les IP accessibles.
Il a trouvé l’UI de sauvegarde. Il a tenté du credential stuffing. Il a eu de la chance.

Le compte rendu post-incident a été douloureux mais éclairant : le VPN n’était pas mal configuré ; il était sous-spécifié.
« Sous-réseau dev » était une histoire que l’on se racontait, pas une frontière appliquée. Ils l’ont corrigé en mettant les services exposés derrière un bastion et en remplaçant la route /16 par une demi-douzaine de /32.
Ils ont aussi imposé des propriétaires pour chaque destination autorisée. Soudain, les « endpoints temporaires » ont cessé d’être invisibles.

Une optimisation qui s’est retournée contre eux : centraliser tout via le bureau

Une autre organisation avait un mélange d’apps SaaS et d’outils internes. Quelqu’un a décidé que le VPN full-tunnel « standardiserait la sécurité » :
tout le trafic client passerait par le siège pour inspection et application de politiques cohérentes.
Sur le papier, c’était propre. En pratique, cela a transformé la passerelle VPN en point d’étranglement et le lien internet du bureau en dorsale officieuse de l’entreprise.

Les premiers symptômes étaient subtils : les appels vidéo « saccadent parfois », les gros uploads « échouent parfois », et les gens blâment leur Wi‑Fi domestique parce que c’est la réaction par défaut.
Puis le changement a été étendu à plus d’utilisateurs. Le DNS est devenu plus lent parce que tout était hairpin via le siège.
Les apps SaaS ont commencé à rate-limiter parce que les requêtes semblaient provenir d’une ou deux IP d’egress.

L’équipe sécurité a répondu en ajoutant plus de règles d’inspection. La latence est remontée encore.
Finalement, l’ingénieur d’astreinte a reçu le ticket redouté : « Le VPN marche mais l’internet est inutilisable. »
Ce n’est pas une énigme réseau ; c’est une dette d’architecture qui a mûri.

Ils sont revenus à du split tunneling pour le trafic internet et ont conservé seulement un jeu restreint de routes internes.
Pour l’inspection, ils ont appliqué des contrôles aux endpoints et au niveau applicatif quand c’était possible.
La leçon : pousser tout le trafic par un point unique est un pari sur la disponibilité. La disponibilité fait partie de la sécurité, même si le tableau de conformité n’est pas d’accord.

La pratique ennuyeuse mais correcte qui a sauvé la situation : listes blanches explicites et notes de changement

Une entreprise proche des finances avait une posture stricte : les utilisateurs VPN obtenaient un pool dédié, et la chaîne forward du pare-feu était en refus par défaut.
Chaque règle d’autorisation avait trois métadonnées : propriétaire du service, raison métier et date de révision d’expiration.
Ça semblait bureaucratique jusqu’à ce que ça ne le soit plus.

Un partenaire a signalé qu’il pouvait soudainement atteindre un service interne qu’il ne devrait pas. La panique a commencé, comme d’habitude.
L’ingénieur d’astreinte n’a pas commencé à « couper le VPN ». Il a vérifié les compteurs de la chaîne forward et a vu des hits sur une règle ajoutée récemment.
Le commentaire de la règle incluait la référence de ticket et le propriétaire.

Le propriétaire a confirmé : pendant une fenêtre de maintenance, il avait temporairement élargi l’accès d’un /32 à un /24 « pour faciliter les tests », et oublié de revenir en arrière.
Parce que la règle était annotée et que le changement était traçable, la correction a pris quelques minutes : revenir la règle au /32 original et redéployer.

Pas de débogage héroïque, pas de guerre de plusieurs heures, pas de blâme vague. Juste une hygiène ennuyeuse qui rapporte.
Si vous voulez de la fiabilité, rendez la réversibilité bon marché et la responsabilité normale.

Erreurs courantes : symptôme → cause racine → correction

1) « Je peux atteindre tout sur 10.x maintenant »

Symptôme : Un utilisateur VPN peut parcourir des partages, des pages d’administration d’imprimante et des UI aléatoires jamais mentionnées dans les exigences.

Cause racine : Routes larges poussées aux clients et politique de forward permissive (souvent accept par défaut) sur la passerelle VPN.

Correction : Supprimez les annonces de route larges ; mettez la politique forward en drop ; ajoutez des autorisations explicites par destination et port. Bloquez client-à-client sauf si nécessaire.

2) « Le VPN marche, mais une appli interne est inaccessible »

Symptôme : Le tunnel est up, le DNS résout, mais les connexions TCP vers un service spécifique expirent.

Cause racine : Autorisation de pare-feu manquante pour ce service/port, ou pare-feu côté destination/groupe de sécurité qui n’autorise pas le pool VPN.

Correction : Vérifiez le tuple dans les règles forward de la passerelle ; examinez compteurs/logs ; ajoutez une autorisation minimale ; mettez à jour les ACLs côté destination. Évitez d’ouvrir des sous-réseaux entiers « juste pour tester ».

3) « Tout est lent sur le VPN ; Zoom meurt ; les logins SaaS sont bizarres »

Symptôme : Après la connexion, la performance internet se dégrade ; le SaaS se comporte de façon imprévisible.

Cause racine : Routage full-tunnel plus DNS détourné via le siège ; concentration des IP d’egress déclenche les contrôles de risque SaaS ; la passerelle devient un goulot d’étranglement.

Correction : Utilisez le split tunneling pour le trafic internet ; ne poussez que les routes internes ; scopez le DNS aux zones internes ; si une inspection est requise, utilisez des contrôles endpoint et des proxies sélectifs.

4) « Ça marche pour certains utilisateurs, échoue pour d’autres »

Symptôme : Même config, résultats différents selon les utilisateurs.

Cause racine : Différences NAT/pare-feu sur les réseaux clients, trous MTU, ou routage/AllowedIPs par utilisateur incohérent.

Correction : Comparez les configs des pairs ; testez le MTU avec des pings DF ; considérez des keepalives ; évitez les routes « snowflake » par utilisateur sauf si nécessaire et documenté.

5) « On ne peut pas savoir qui a accédé à quoi »

Symptôme : Les logs montrent seulement l’IP de la passerelle à cause du NAT, ou les utilisateurs partagent des clés.

Cause racine : La masquerade cache l’IP client ; absence d’identifiants par utilisateur ; mauvaise corrélation des logs.

Correction : Préférez des pools routés sans NAT ; imposez des clés/certificats par utilisateur ; annotez les clés ; loggez les connexions/déconnexions avec identité et IP assignée.

6) « Après la fusion, le VPN a cassé et maintenant les routes fluctuent »

Symptôme : Certaines plages internes routent de façon intermittente vers le mauvais endroit ; la résolution de noms pointe vers des IP inatteignables.

Cause racine : Ranges RFC1918 qui se chevauchent combinés via VPN ; routes ambiguës ; split-horizon DNS pas aligné avec la portée réelle.

Correction : Renumérotez si possible ; sinon utilisez le NAT à des frontières claires avec forte journalisation ; rendez le routage plus spécifique ; alignez les vues DNS avec les réseaux réellement atteignables.

7) « Les clients VPN peuvent se scanner entre eux »

Symptôme : Un client peut se connecter aux ports exposés d’un autre client via les IP VPN.

Cause racine : Client-à-client autorisé (OpenVPN client-to-client activé, ou règles forward permettant wg0→wg0).

Correction : Désactivez client-à-client ; bloquez le forwarding wg0→wg0 ; si le trafic pair est requis, imposez une politique explicite et considérez des pools/groupes séparés.

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

Étape par étape : migration du LAN-à-LAN complet vers un VPN à moindre privilège

1. Inventoriez ce dont les utilisateurs ont réellement besoin
   • Listez des applications/services, pas des sous-réseaux. « Git via HTTPS », « RDP vers jump host », « Postgres vers DB reporting ».
   • Identifiez des propriétaires pour chaque service et une raison métier.
2. Définissez un pool client VPN dédié et segmentez
   • Choisissez une plage non chevauchante (ex., 10.250.0.0/24).
   • Routez-la correctement (pas de NAT si vous pouvez l’éviter).
3. Mettez le forwarding depuis le VPN en refus par défaut
   • Politique de la chaîne forward en drop, allow established/related.
   • Autorisez explicitement les destinations/ports minimaux.
4. Réduisez les routes poussées aux clients
   • Pour WireGuard : resserrez AllowedIPs par pair/groupe.
   • Pour OpenVPN : poussez des routes spécifiques seulement.
5. Mettez l’accès admin derrière des bastions
   • Privilégiez des gateways SSH/RDP avec MFA et journalisation.
   • Puis autorisez bastion → cible, pas client → cible.
6. Scopez le DNS
   • Zones internes seulement ; évitez de forcer tout le DNS via le VPN sauf si nécessaire.
   • Faites en sorte que les noms internes résolvent vers des IP atteignables pour les clients VPN (pas d’enregistrements split-horizon « morts »).
7. Ajoutez le mapping d’identité et l’hygiène des clés
   • Clés/certs par utilisateur, pas de secrets partagés.
   • Annotez propriété, but et date de revue à côté de la config.
8. Ajoutez des logs que vous utiliserez réellement
   • Événements de connexion + IP assignée, refus pare-feu (échantillonnés), requêtes DNS pour zones internes (si faisable).
   • Rendez cela interrogeable par utilisateur, IP VPN et destination.
9. Déployez par phases
   • Commencez par un groupe pilote et les 5 principaux services.
   • Laissez l’ancien accès large derrière un toggle d’urgence, mais avec une date d’expiration sur ce toggle.
10. Faites un exercice table-top d’incident
    • Exercez : « Clé de contractuel compromise, que peut-il atteindre ? »
    • Si la réponse est « la plupart du LAN », vous n’avez pas fini.

Checklist opérationnelle : ajout d’un nouveau service autorisé

• Le propriétaire du service approuve et fournit l’IP/hostname et le(s) port(s) de destination.
• Décidez : accès direct vs via bastion/proxy.
• Confirmez que les ACL côté destination autorisent le pool VPN (routé, pas NATé, idéalement).
• Ajoutez une règle de pare-feu allow avec un commentaire incluant propriétaire/buty date de revue.
• Ajoutez seulement la route nécessaire (préférez /32 ou le plus petit sous-réseau qui héberge le service).
• Testez depuis un réseau client représentatif (NAT domestique, hotspot mobile, Wi‑Fi corporate).
• Confirmez que les logs montrent l’identité de l’utilisateur pour les tentatives d’accès et les refus.

Checklist sécurité : maintenir le modèle serré dans le temps

• Revue trimestrielle des destinations autorisées par groupe/pair.
• Expiration automatique des accès fournisseurs sauf renouvellement.
• Alerte sur nouvelles annonces de routes larges ou changements des politiques par défaut.
• Bloquez les protocoles dangereux connus (SMB, RPC) depuis le VPN sauf si explicitement requis et contraint.
• Exigez des baselines OS et sécurité endpoint pour les appareils gérés.

FAQ

1) Le « LAN-à-LAN complet » n’est-il pas plus simple et donc plus sûr ?

C’est plus simple de la même manière que retirer les freins simplifie une voiture.
Moins de pièces, moins de décisions—jusqu’à la première fois où vous devez freiner. Le LAN-à-LAN complet augmente le rayon d’explosion et complique les audits et la réponse aux incidents.
Une simplicité qui accroît le risque n’est pas de la simplicité opérationnelle.

2) Le split tunneling semble risqué. Ne devrait-on pas faire passer tout le trafic par les outils de sécurité corporate ?

Si vous pouvez garantir capacité, fiabilité et inspection correcte sans casser le SaaS, le full-tunnel peut être défendable.
La plupart des organisations ne le peuvent pas. Une approche pragmatique est le split tunnel pour Internet, des routes strictes pour les services internes, et des contrôles de sécurité endpoint pour le reste.
Centraliser tout via le siège est un pari sur la disponibilité que vous prenez chaque jour ouvrable.

3) Puis-je me fier uniquement à WireGuard AllowedIPs pour le contrôle d’accès ?

AllowedIPs est nécessaire mais pas suffisante. C’est un levier fort, mais vous voulez toujours des règles de pare-feu sur la passerelle et des ACLs côté destination.
La défense en profondeur compte parce que quelqu’un finira par ajouter une route « temporaire ».

4) Les clients VPN doivent-ils être NATés vers la passerelle ?

Évitez le NAT quand vous le pouvez : il supprime l’attribution côté destination et complique les audits.
Utilisez des pools routés et apprenez au côté LAN à retourner le trafic vers le sous-réseau VPN. Le NAT est parfois requis pour des réseaux legacy,
mais considérez-le comme un compromis et ajoutez des contrôles compensatoires.

5) Comment empêche-t-on les utilisateurs VPN de découvrir des noms d’hôtes internes ?

Scopez le DNS. Ne donnez pas un résolveur qui peut répondre à tout l’espace de noms interne si les utilisateurs n’ont besoin que d’une zone.
Utilisez le forwarding conditionnel ou un routage DNS par lien, et évitez de divulguer les zones « mgmt » aux utilisateurs généraux.

6) Et si « l’appli utilise des ports dynamiques » ?

C’est un fort indice que vous ne devriez pas autoriser l’application directement via le VPN.
Mettez-la derrière une passerelle qui normalise l’accès (proxy, bastion, ports publiés fixes), ou repensez l’exposition du service.
Les ports dynamiques sont acceptables à l’intérieur d’un segment contrôlé ; ils ne sont pas acceptables comme exigence de politique VPN.

7) Comment gérer les fournisseurs qui ont besoin d’accès « juste pour une semaine » ?

Traitez l’accès fournisseur comme expirant par défaut. Émettez des identifiants par fournisseur, restreignez les routes au service spécifique, et définissez une date de revue/expiration.
Si le travail s’étend, renouvelez délibérément. « C’est encore nécessaire » doit être un choix, pas la conséquence d’un oubli.

8) Quelle est la configuration minimale viable si nous sommes petits et occupés ?

Pool VPN dédié, forwarding par défaut en refus, et un bastion pour l’accès admin.
Ajoutez une petite poignée d’autorisations explicites de service. Annotez tout avec la propriété.
Vous pouvez évoluer vers des accès conscient de l’identité plus tard, mais vous ne pouvez pas rétrécir rétroactivement un réseau plat sans douleur.

9) Comment empêcher que le moindre privilège ne tourne en ping-pong interminable de tickets ?

Créez un parcours standard d’onboarding de service : les propriétaires fournissent destination/ports, vous appliquez un modèle de règle, et vous révisez trimestriellement.
Poussez aussi les équipes vers des proxies/bastions afin que l’accès soit accordé à un point de contrôle, pas en saupoudrant des règles de pare-feu sur le LAN.
L’objectif est moins de décisions, pas plus.

Conclusion : prochaines étapes pratiques

Le VPN de bureau n’est pas une extension de votre LAN. C’est un produit d’accès, et comme tout produit il a besoin d’un contrat clair :
qui peut atteindre quoi, par quels chemins, avec quels logs, et avec quelle expiration.
Si vous ne pouvez pas énoncer le contrat, vous n’avez pas le contrôle—vous avez de la connectivité.

Prochaines étapes que vous pouvez faire cette semaine :

1. Choisissez un groupe VPN (fournisseurs ou contractuels sont idéaux) et remplacez les routes larges par des destinations explicites.
2. Passez le forwarding en refus par défaut et ajoutez seulement les règles allow nécessaires avec commentaires et dates de revue.
3. Décidez si le NAT masque votre capacité d’audit ; si oui, planifiez une migration vers un pool routé.
4. Scopez le DNS aux zones internes réellement requises.
5. Rédigez le playbook « Diagnostic rapide » et gardez-le près du runbook d’astreinte, pas dans la tête de quelqu’un.

Faites-le correctement et votre VPN devient une infrastructure ennuyeuse : prévisible, explicable et sans intérêt.
C’est le plus grand compliment que reçoivent les systèmes de production.