VPN de bureau + VLAN : connecter les segments en toute sécurité sans aplatir le réseau

Le modèle mental : le VPN est un routeur, pas un couloir magique

Les VLAN servent à séparer les domaines de diffusion et à créer des frontières administratives. Les VPN transportent du trafic à travers un réseau non fiable ou peu pratique.
Les combiner maladroitement et vous n’obtenez pas « un accès distant sécurisé ». Vous obtenez « encore un chemin vers tout », avec moins d’yeux dessus.

Si vous retenez une chose : un client VPN d’accès distant est un hôte sur une nouvelle interface. Il a besoin de routage, DNS et règles de pare-feu comme n’importe quel autre hôte.
Le traiter comme « intérieur » est la façon dont vous aplatissez le réseau sans même le remarquer.

À quoi ressemble généralement « l’aplatissement »

• Les clients VPN reçoivent une adresse dans un sous‑réseau « de confiance » qui peut router vers tous les VLAN.
• Les règles de pare‑feu disent « VPN → LAN allow » parce qu’un ticket exigeait « que ça fonctionne ».
• Le split tunneling est désactivé « pour la sécurité », donc chaque utilisateur distant devient un routeur en épingle à cheveux via votre bureau.
• Personne ne peut répondre à « quel utilisateur VPN a accédé à quel service VLAN » sans deviner.

L’objectif n’est pas de rendre les utilisateurs VPN malheureux. L’objectif est de rendre leur accès délibéré : réseaux spécifiques, ports spécifiques, identités spécifiques, avec des journaux exploitables.

Quelques faits (et un peu d’histoire) qui changent les décisions

1. Les VLAN proviennent de IEEE 802.1Q (fin des années 1990) comme moyen de segmentation logique sur une infrastructure de commutation partagée. Ils n’ont jamais été conçus pour être seuls un système de contrôle d’accès.
2. IPsec a été conçu pour des réseaux hostiles, mais les déploiements en entreprise utilisent souvent des politiques « allow any » parce que négocier « ce qui doit être autorisé » est socialement plus difficile que la cryptographie.
3. Les premiers VPN d’accès distant pontaient souvent la couche 2 (appareils TAP, « bridge mode »), ce qui rendait la découverte Windows et les protocoles hérités heureux — et les équipes de sécurité moins heureuses plus tard.
4. Le NAT est devenu la norme accidentelle pour les réseaux domestiques, d’où les problèmes d’adresses RFC1918 chevauchantes que rencontrent encore les VPN en 2025.
5. Le split tunneling précède le « Zero Trust » moderne de plusieurs décennies. Ce n’est pas automatiquement peu sûr ; c’est risqué quand vous ne contrôlez pas la posture des appareils et la politique d’egress.
6. La segmentation réseau est historiquement née autant de besoins de fiabilité que de sécurité : limiter les tempêtes de broadcast et isoler les pannes était un moteur pratique bien avant que le ransomware n’apparaisse sur toutes les slides.
7. 802.1X NAC (authentification basée sur le port) a tenté de faire de la question « qui est sur ce port ? » une priorité. Beaucoup d’organisations ne le déploient pas encore car cela demande de la discipline opérationnelle.
8. Penser « VPN à l’intérieur du périmètre » est un vestige de l’époque où « l’intérieur » signifiait « employés sur postes d’entreprise ». BYOD et SaaS ont transformé cela en folklore.

La conclusion : les VLAN sont des frontières, les VPN sont un transport. La sécurité se fait dans la politique de routage, les règles de pare‑feu, l’identité et la journalisation. Pas dans l’ambiance.

Objectifs de conception pour éviter le « réseau plat par accident »

1) Atteignabilité explicite : le moins de routes, pas le plus d’espoir

Votre VPN ne doit annoncer que ce dont un groupe d’utilisateurs a besoin. Si le client peut router vers tous les VLAN, quelqu’un finira par essayer. Parfois par accident, parfois pas.
Une conception propre utilise des pushs de routes par groupe, ou des AllowedIPs par pair (WireGuard), ou au minimum du filtrage par pool d’adresses au niveau du pare‑feu.

2) Faire respecter la segmentation en couche 3/4 (et parfois 7)

Les VLAN gardent la commutation saine. Les pare‑feu gardent le business sain. Placez l’application des règles là où vous pouvez la journaliser, la revoir et la tester : à la frontière inter‑VLAN et à l’ingress VPN.
« Mais le switch supporte des ACL » est vrai — et aussi la façon dont vous vous retrouvez avec des règles que personne ne peut auditer.

3) Ne transformez pas le VPN en transit pour tout Internet à moins que ce soit voulu

Le full‑tunnel VPN est parfois requis (environnements réglementés, contrôle strict de l’egress, voyages hostiles). Mais c’est un choix coûteux :
bande passante, latence, charge sur le pare‑feu du bureau, et les inévitables tickets « Zoom est lent ».
Si vous faites du full‑tunnel, concevez‑le : capacité, QoS et contrôles d’egress clairs.

4) Rendre l’identité visible dans les journaux

« 10.9.0.23 a accédé à 10.20.30.40 » est faible. Vous voulez « alice@corp sur appareil X a accédé à finance-api sur le port 443 ».
Cela exige une authentification VPN liée à l’identité (SAML/OIDC/RADIUS) et des journaux qui incluent l’utilisateur, l’IP assignée et la durée de session.

5) Rendre les chevauchements et la croissance ennuyeux

La prolifération des VLAN arrive. Les fusions/acquisitions aussi. Planifiez votre espace d’adressage pour pouvoir ajouter des segments sans renumérotation, et évitez les chevauchements avec les réseaux domestiques courants.
Si votre LAN de bureau est 192.168.0.0/16, vous méritez la douleur à venir.

Blague #1 : « On permettra juste VPN → LAN pour l’instant » revient à « je vais jongler avec des tronçonneuses jusqu’à ce que l’auditeur parte ». Ça marche jusqu’au moment où ça ne marche plus.

Architectures recommandées (et quand les utiliser)

Patron A : Le VPN arrive dans un VLAN « Utilisateurs VPN » dédié + routage strict

C’est l’outil de travail. Les utilisateurs VPN obtiennent un pool IP qui mappe à un VLAN dédié ou à une interface routée (pas forcément un VLAN, mais souvent).
Le routage inter‑VLAN depuis ce segment est contrôlé par une politique de pare‑feu.

Quand l’utiliser : La plupart des bureaux, surtout si vous avez plusieurs VLAN internes (corp, serveurs, VoIP, imprimantes, IoT, guest).

Pourquoi c’est bien : Un point d’étranglement. Un endroit pour journaliser. Vous pouvez appliquer une politique différente aux utilisateurs VPN qu’aux clients sur site dans le même VLAN « corp ».

Mode d’échec : Quelqu’un s’impatiente et ajoute « VPN → any allow » parce qu’un service interne utilisait une plage de ports éphémères bizarre et personne ne voulait corriger l’appli.

Patron B : Accès par application via reverse proxy / bastion (pas d’accès VLAN général)

Tout n’a pas besoin d’un accès couche réseau. Les applis web internes peuvent être publiées derrière un proxy aware d’identité. SSH peut passer par un bastion avec certificats courts.
Le RDP peut être brokerisé.

Quand l’utiliser : Environnements hautement réglementés, organisations remote‑first, ou quand le réseau interne est majoritairement legacy et peu fiable.

Pourquoi c’est bien : Vous arrêtez de faire semblant que « accès réseau » équivaut à « accès appli ». Ce n’est pas le cas.

Mode d’échec : Les équipes contournent la solution en exposant des ports aléatoires « temporairement ». Temporarily est la plus longue unité de temps en IT.

Patron C : VPN site‑à‑site entre bureaux avec routage conscient des VLAN

Le site‑à‑site est une autre bête : deux domaines de routage, points d’extrémité généralement stables, et pression pour tout connecter à tout.
Ne le faites pas. Routez seulement les sous‑réseaux nécessaires entre sites, et maintenez des règles de pare‑feu inter‑site aussi strictes que tolérables.

Quand l’utiliser : Succursales, entrepôts, points de vente, usines.

Mode d’échec : Sous‑réseaux qui se chevauchent (les deux sites utilisent 10.0.0.0/24) et quelqu’un « corrige » ça avec du NAT qui casse Kerberos, la journalisation et le dépannage.

Patron D : Segmentation basée VRF + VPN par VRF

Si vous avez une vraie équipe réseau et du matériel qui le supporte, les VRF sont la version « adulte » de beaucoup de VLANs.
Vous pouvez faire tourner des tables de routage séparées (corp, OT, guest) et attacher la terminaison VPN au VRF correct avec un filtrage de fuite de routes strict.

Quand l’utiliser : Environnements moyens à grands, ou partout où des réseaux OT/ICS ne doivent pas se mélanger.

Mode d’échec : La fuite de routes devient « juste une exception de plus », et soudain vos VRF sont un musée de compromis passés.

Routage + pare‑feu : les règles qui comptent vraiment

Décidez où le routage inter‑VLAN se produit

Choisissez un endroit : le switch central (SVIs), ou un pare‑feu/routeur. Si vous routez sur le switch, vous avez toujours besoin d’un point d’application des règles quelque part.
Le modèle opérationnel le plus propre est : le switch fait le forwarding L2/L3, le pare‑feu applique la politique aux frontières (via des liens routés, ACLs, ou des designs « firewall‑on‑a‑stick »).

Mon biais : si vous tenez à la segmentation comme sécurité, faites appliquer sur un pare‑feu avec journalisation. Les ACLs switch sont utiles comme garde‑fous, pas pour votre récit principal de sécurité.

Politique d’ingress VPN : traitez‑la comme un VLAN hostile

Les appareils distants sont variables. Même les laptops gérés passent du temps sur des Wi‑Fi d’hôtels, réseaux domestiques et cafés avec des portails captifs conçus par le chaos.
Donc votre sous‑réseau VPN doit être traité plutôt comme « semi‑fiable » que comme « LAN corp ».

• Autoriser VPN → DNS (vos résolveurs), NTP, et applications internes requises.
• Bloquer VPN → réseaux de management (switch, pare‑feu, gestion d’hyperviseur) par défaut.
• Bloquer VPN → VLAN utilisateurs sauf si cas d’usage justifié (outils helpdesk, etc.).
• Journaliser les refus pour alerte précoce. Puis affiner pour réduire le bruit.

L’annonce de routes est un contrôle de sécurité

Les pare‑feu sont votre dernière ligne. Le routage est votre première ligne. Si vous poussez les routes de tous les sous‑réseaux à tous les clients, vous invitez au mouvement latéral.
Dans WireGuard, AllowedIPs est à la fois « quelles routes le client installe » et « quelles sources le serveur accepte ». C’est puissant. Utilisez‑le.

Soyez intentionnel sur le split tunneling

Le split tunnel signifie que seuls les sous‑réseaux internes passent par le VPN ; tout le reste va directement sur Internet. Le risque n’est pas « Internet ». Le risque est un endpoint compromis qui peut parler aux deux mondes.
Vous atténuez cela par des vérifications de posture d’appareil, de la sécurité endpoint, et en restreignant ce que le VPN peut atteindre.

Le full tunnel signifie que tout transite par votre bureau. Le risque est que votre bureau devienne le goulot d’étranglement de tous et que vos journaux deviennent un champ de mines privacy & compliance.
Choisissez selon les besoins de contrôle d’egress, pas par peur.

Une citation, parce que c’est toujours vrai

L’espoir n’est pas une stratégie. — idée paraphrasée souvent attribuée aux ingénieurs et opérateurs en fiabilité

(Non, je ne parie pas la sécurité de production sur l’origine exacte d’un slogan. Vous ne devriez pas non plus.)

DNS, identité, et pourquoi penser seulement en IP échoue

DNS : rendez‑le ennuyeux et cohérent

Les utilisateurs VPN ont besoin d’une résolution de noms qui corresponde à la réalité on‑prem, sinon vous finirez avec des hosts files parallèles et des IP mystères dans les favoris.
Utilisez du split DNS : les domaines internes se résolvent via des résolveurs internes ; les noms publics via les résolveurs normaux (ou votre egress contrôlé si full‑tunnel).

Aussi : décidez si les clients VPN peuvent résoudre des noms internes qu’ils ne peuvent pas atteindre. Dans des environnements stricts, vous pouvez empêcher cela intentionnellement pour réduire la reconnaissance.

Identité : lier l’accès au qui, pas seulement au où

La segmentation VLAN est le « où ». Le VPN ajoute le « comment vous êtes arrivé ». Il vous faut toujours le « qui ».
Si votre authentification VPN est juste une PSK partagée, vous avez une bombe à retardement. Utilisez une authentification par utilisateur avec MFA, certificats/clés courte durée, et autorisation basée sur les groupes.

Observabilité : des journaux qui répondent aux questions de sécurité

Vous voulez pouvoir répondre :

• Quel utilisateur avait l’IP 10.90.0.14 à 14:32 ?
• Quelles destinations internes cette session a‑t‑elle contactées ?
• Ont‑elles été refusées par la politique, et pourquoi ?
• Ce trafic était‑il normal pour leur rôle ?

Si votre stack actuel ne peut pas répondre à ça sans une chasse manuelle, corrigez‑le avant d’élargir la portée du VPN.

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

Ce sont des vérifications réelles à exécuter pendant la conception et la réponse aux incidents. Chaque item inclut : la commande, ce que signifie la sortie, et la décision à prendre.
Supposez une passerelle/pare‑feu VPN basée sur Linux quand c’est pertinent ; adaptez à votre plateforme.

Task 1: Confirm the VPN interface and assigned address

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             203.0.113.10/24
vlan20@eth1      UP             10.20.0.1/24
vlan30@eth1      UP             10.30.0.1/24
wg0              UP             10.90.0.1/24

Signification : wg0 est votre interface VPN ; le pool client VPN est 10.90.0.0/24.

Décision : Traitez 10.90.0.0/24 comme son propre segment dans la politique de pare‑feu. Ne le regroupez pas avec le « LAN ».

Task 2: Verify which routes VPN clients are expected to reach

cr0x@server:~$ ip route show
default via 203.0.113.1 dev eth0
10.20.0.0/24 dev vlan20 proto kernel scope link src 10.20.0.1
10.30.0.0/24 dev vlan30 proto kernel scope link src 10.30.0.1
10.90.0.0/24 dev wg0 proto kernel scope link src 10.90.0.1

Signification : La passerelle route entre VLAN20, VLAN30 et le sous‑réseau VPN.

Décision : Si vous n’avez pas l’intention que les clients VPN atteignent VLAN30, ne comptez pas sur « on le bloquera plus tard ». Retirez les pushes de routes vers les clients et ajoutez des refus au pare‑feu.

Task 3: Check WireGuard peers and AllowedIPs (route scope)

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

peer: w9h...redacted...
  preshared key: (hidden)
  endpoint: 198.51.100.25:53644
  allowed ips: 10.90.0.23/32, 10.20.10.0/24
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.23 GiB received, 5.44 GiB sent

Signification : Cet utilisateur peut sourcer du trafic en tant que 10.90.0.23 et est autorisé à atteindre (et/ou router) 10.20.10.0/24, selon votre topologie.

Décision : Resserrez les allowed ips à ce dont ils ont besoin. Évitez de donner à un pair des sous‑réseaux larges « pour la commodité ».

Task 4: Confirm IP forwarding is enabled on the gateway

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

Signification : Le système va router entre les interfaces.

Décision : Si vous attendiez que la passerelle soit un endpoint strict (pas de routage), désactivez le forwarding et redessinez. Si vous attendez du routage, laissez‑le activé et appliquez la politique de pare‑feu.

Task 5: Inspect firewall default policy (nftables)

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
    iif "eth0" tcp dport 22 accept
    iif "eth0" udp dport 51820 accept
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iif "wg0" oif "vlan20" tcp dport { 443, 5432 } accept
    iif "wg0" oif "vlan20" udp dport 53 accept
    iif "wg0" oif "vlan30" drop
  }
}

Signification : Drop par défaut. Le VPN peut atteindre des ports TCP spécifiques sur VLAN20, peut faire du DNS, et est explicitement bloqué pour VLAN30.

Décision : C’est la forme désirée : listes d’autorisation explicites, refus explicites quand nécessaire, et un refus par défaut explicable.

Task 6: Confirm the VPN isn’t accidentally NATing into “trusted” LAN

cr0x@server:~$ sudo nft list table ip nat
table ip nat {
  chain postrouting {
    type nat hook postrouting priority 100; policy accept;
    oif "eth0" masquerade
  }
}

Signification : Seul le trafic vers Internet est masqué sur eth0. Le trafic interne VLAN n’est pas masqueradé.

Décision : Évitez le NAT entre VPN et VLAN internes sauf si vous y êtes contraint par des sous‑réseaux chevauchants. Le NAT masque l’identité et complique la journalisation.

Task 7: Validate that inter-VLAN access is actually blocked (from a VPN client)

cr0x@server:~$ nc -vz 10.30.0.10 22
nc: connect to 10.30.0.10 port 22 (tcp) failed: Operation timed out

Signification : La connexion n’aboutit pas ; probablement bloquée par la politique de pare‑feu (ou routage/hôte indisponible).

Décision : Confirmez dans les journaux du pare‑feu. Si vous voyez « drop wg0→vlan30 », vous appliquez la segmentation correctement.

Task 8: Verify allowed app access is working (and not wider than needed)

cr0x@server:~$ nc -vz 10.20.0.50 5432
Connection to 10.20.0.50 5432 port [tcp/postgresql] succeeded!

Signification : Le client VPN peut atteindre le service Postgres sur le port approuvé.

Décision : Si c’est le seul accès requis, conservez cette granularité. Si l’appli a besoin de plus de ports, documentez‑les et envisagez un proxy applicatif plutôt que d’élargir le réseau.

Task 9: Check path MTU and fragmentation risk (classic VPN throughput killer)

cr0x@server:~$ ping -M do -s 1360 10.90.0.1 -c 3
PING 10.90.0.1 (10.90.0.1) 1360(1388) bytes of data.
1368 bytes from 10.90.0.1: icmp_seq=1 ttl=64 time=22.1 ms
1368 bytes from 10.90.0.1: icmp_seq=2 ttl=64 time=21.7 ms
1368 bytes from 10.90.0.1: icmp_seq=3 ttl=64 time=21.9 ms

--- 10.90.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

Signification : Une charge utile de 1360 octets avec DF défini réussit. Cela suggère que votre MTU effectif est d’au moins ~1388 sur ce chemin.

Décision : Si cela échoue, baissez le MTU de l’interface VPN (ou corrigez PMTUD). Ne « optimisez » pas en ignorant le MTU ; il vous optimisera en tickets.

Task 10: Capture traffic on the VPN interface to see what’s really happening

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.90.0.23 and tcp port 5432 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:44:01.121901 IP 10.90.0.23.49212 > 10.20.0.50.5432: Flags [S], seq 381909112, win 64240, options [mss 1360,sackOK,TS val 101 ecr 0,nop,wscale 7], length 0
12:44:01.138221 IP 10.20.0.50.5432 > 10.90.0.23.49212: Flags [S.], seq 21188218, ack 381909113, win 65160, options [mss 1460,sackOK,TS val 55 ecr 101,nop,wscale 7], length 0
12:44:01.138309 IP 10.90.0.23.49212 > 10.20.0.50.5432: Flags [.], ack 1, win 502, options [nop,nop,TS val 102 ecr 55], length 0

Signification : SYN/SYN‑ACK/ACK complète. Le chemin réseau fonctionne ; si l’appli est toujours « down », c’est probablement authentification appli, DNS ou erreur utilisateur — pas du routage.

Décision : Arrêtez de modifier les règles du pare‑feu. Escaladez vers les propriétaires d’applications avec la preuve.

Task 11: Confirm DNS resolution path for internal names

cr0x@server:~$ resolvectl status | sed -n '1,120p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub

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

Signification : Le DNS pour l’interface VPN pointe vers le résolveur interne et le domaine de recherche est défini.

Décision : Si les utilisateurs VPN ne peuvent pas résoudre *.corp.example, corrigez les options DHCP pour le VPN ou le push de configuration client VPN. Ne dites pas aux utilisateurs de « juste utiliser des IP ». C’est comme ça que les erreurs deviennent des incidents.

Task 12: Check which connections are active and whether they’re stuck

cr0x@server:~$ ss -tnp | sed -n '1,12p'
State   Recv-Q  Send-Q   Local Address:Port    Peer Address:Port  Process
ESTAB   0       0        10.90.0.1:5432        10.90.0.23:49212   users:(("postgres",pid=2214,fd=7))
SYN-RECV 0      0        10.20.0.50:443        10.90.0.23:51044   users:(("nginx",pid=1893,fd=15))

Signification : Une session BD établie est saine. Le SYN‑RECV indique des handshakes TCP à moitié ouverts — souvent asymétrie de pare‑feu, problèmes de routage retour, ou MTU.

Décision : Investiguer la symétrie du chemin et le suivi d’état du pare‑feu ; vérifier les routes de retour depuis 10.20.0.50 vers 10.90.0.0/24.

Task 13: Verify return routing from an internal server VLAN

cr0x@server:~$ ip route get 10.90.0.23 from 10.20.0.50 iif vlan20
10.90.0.23 from 10.20.0.50 iif vlan20
  via 10.20.0.1 dev vlan20 src 10.20.0.50 uid 0
    cache

Signification : Les réponses depuis VLAN20 passeront via la passerelle à 10.20.0.1, qui peut router vers wg0.

Décision : Si cela pointe vers un autre routeur, vous avez du routage asymétrique. Corrigez la gateway par défaut ou ajoutez une route statique. Ne « corrigez » pas ça avec du NAT sauf si vous aimez dépanner à l’aveugle.

Task 14: Check firewall counters to see what’s being dropped

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 "vlan20" tcp dport { 443, 5432 } accept
    iif "wg0" oif "vlan20" udp dport 53 accept
    iif "wg0" oif "vlan30" drop counter packets 1842 bytes 122004
  }
}

Signification : Le trafic du VPN vers VLAN30 est droppé, et ce n’est pas hypothétique — il y a des compteurs.

Décision : Décidez si c’est attendu (bien : vous empêchez le mouvement latéral) ou si c’est une dépendance mal documentée (mauvais : l’appli a réellement besoin de VLAN30). Dans tous les cas, vous avez maintenant une preuve.

Task 15: Measure VPN gateway CPU and crypto bottlenecks

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (vpn-gw)  12/28/2025  _x86_64_  (8 CPU)

01:02:11 PM  CPU  %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
01:02:12 PM  all  12.5  0.0  38.1   0.0    0.0  31.4    0.0    0.0    0.0   18.0
01:02:12 PM    3  10.0  0.0  44.0   0.0    0.0  42.0    0.0    0.0    0.0    4.0

Signification : Un %soft et %sys élevé suggère que le traitement de paquets est chaud ; un CPU est presque saturé. Ça peut limiter le débit.

Décision : Envisagez d’activer le multiqueue/réglages NIC, de déplacer la terminaison VPN sur du matériel plus puissant, ou d’utiliser une implémentation noyau. Ne rejetez pas « l’ISP » sans avoir regardé ici.

Task 16: Check conntrack table pressure (stateful firewall pain)

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 183742
net.netfilter.nf_conntrack_max = 262144

Signification : Vous êtes à ~70% de la capacité conntrack. Des pics peuvent provoquer des drops et des comportements étranges.

Décision : Augmentez la taille conntrack et/ou réduisez les flux inutiles (surtout si full‑tunnel). Si vous tournez tout le streaming des utilisateurs via vous, vous en payez le prix en états.

Guide de diagnostic rapide

Quand VPN + accès VLAN « marche à moitié » et que tout le monde propose des changements de pare‑feu au hasard, faites plutôt ceci.
L’objectif est de trouver le goulot en quelques minutes, pas après une semaine de folklore.

Première étape : isolez la classe de panne

1. Est‑ce la connectivité ? Le client peut‑il pinguer l’IP passerelle VPN ? Peut‑il atteindre une IP de service interne connue sur un port connu ?
2. Est‑ce la résolution de noms ? Le DNS interne se résout‑il ? Se résout‑il à la bonne IP pour le segment de cet utilisateur ?
3. Est‑ce la politique ? Les compteurs/journaux du pare‑feu montrent‑ils des drops pour cette IP source et cette destination ?
4. Est‑ce la performance ? De petits pings fonctionnent mais de gros transferts stagnent ? Pensez MTU, CPU, conntrack et routes asymétriques.

Deuxième étape : vérifiez la symétrie de routage

1. Depuis la passerelle : la route vers le VLAN de destination existe.
2. Depuis le VLAN de destination : la route de retour vers le sous‑réseau VPN existe via la même passerelle.
3. Sur les pare‑feu : le suivi d’état voit les deux directions sur le même équipement.

Troisième étape : confirmez les routes installées sur le client VPN

La plupart des tickets « le VPN ne peut pas atteindre le sous‑réseau X » sont « le client n’a jamais installé la route vers X » ou « le client a une route plus spécifique vers un réseau local ».
C’est là que les chevauchements RFC1918 mordent.

Quatrième étape : testez le MTU tôt

Les problèmes de MTU VPN gaspillent du temps parce qu’ils se déguisent en « lenteur aléatoire » et « certains sites fonctionnent, d’autres non ».
Lancez des pings DF avec des tailles croissantes jusqu’à trouver le plafond, puis fixez le MTU volontairement.

Cinquième étape : regardez la capacité sur le point de terminaison

CPU softirq élevé, conntrack proche du max, drops de ring NIC, ou un processus VPN utilisateur mono‑thread peuvent tous limiter le débit.
Si vous full‑tunneling, considérez que vous êtes devenu un ISP. Agissez en conséquence.

Erreurs courantes : symptôme → cause racine → correctif

1) « Les utilisateurs VPN peuvent tout atteindre sur tous les VLAN »

Symptôme : La revue sécurité constate que le pool VPN peut atteindre imprimantes, hyperviseurs et IP de management aléatoires.

Cause racine : Le sous‑réseau VPN traité comme « LAN de confiance » et autorisé via des règles de routage inter‑VLAN.

Correctif : Placez les utilisateurs VPN dans une zone politique dédiée ; passez à une politique de forward par défaut deny ; allowlistez seulement les ports et destinations nécessaires.

2) « Certaines applis internes fonctionnent, d’autres bloquent ou sont très lentes »

Symptôme : SSH marche, mais les transferts de fichiers stagnent ; HTTPS charge partiellement ; RDP gèle.

Cause racine : Échec MTU/PMTUD à travers le VPN, souvent avec overhead d’encapsulation et ICMP fragmentation‑needed bloqué.

Correctif : Autorisez les types ICMP pertinents ; baissez le MTU de l’interface VPN ; testez avec des pings DF ; évitez la double encapsulation quand possible.

3) « Ça marchait hier ; aujourd’hui un seul VLAN est inaccessible depuis le VPN »

Symptôme : Le VPN atteint le VLAN serveur mais pas le VLAN corp, ou vice versa.

Cause racine : Le chemin de retour a changé (nouveau core switch, bascule VRRP, route statique supprimée). Le routage asymétrique casse les pare‑feu stateful.

Correctif : Assurez‑vous que la gateway par défaut du VLAN de destination renvoie via la passerelle VPN/pare‑feu ; ajoutez des routes explicites ; évitez de contourner le point d’application de la politique.

4) « Après activation du full‑tunnel, l’Internet du bureau est devenu catastrophique »

Symptôme : Tout le monde se plaint, et les graphes montrent une montée CPU et sessions sur le pare‑feu.

Cause racine : Le full‑tunnel a transformé votre concentrateur VPN en gateway d’egress sans plan de capacité ; conntrack et tables NAT sont saturés.

Correctif : Revenez au split tunnel avec contrôles de posture, ou scalez le concentrateur et l’egress ; ajoutez du QoS ; contrôlez ce qui peut transiter.

5) « Les clients VPN ne peuvent pas atteindre les sous‑réseaux internes depuis chez eux »

Symptôme : Les sous‑réseaux du bureau se chevauchent avec ceux du routeur domestique ; les routes client pointent local au lieu du VPN.

Cause racine : Collision de plan d’adressage (ex. le bureau utilise 192.168.1.0/24).

Correctif : Meilleur : éviter les chevauchements par une planification d’adressage corporative sensée (n’utilisez pas les plages domestiques courantes). À défaut, dernier recours : NAT par client sur le VPN ou renumérotation. Le NAT marche mais complique identité, journalisation et certains protocoles.

6) « Le DNS résout, mais les utilisateurs atteignent le mauvais service »

Symptôme : Un nom se résout vers une IP joignable mais pas l’environnement voulu (prod vs staging, bureau vs cloud).

Cause racine : Mauvaise configuration du split DNS ; domaines de recherche qui poussent une résolution FQDN inattendue ; multiples zones internes avec enregistrements incohérents.

Correctif : Standardisez les zones DNS internes ; configurez explicitement le DNS VPN ; auditez les domaines de recherche ; journalisez les requêtes DNS du pool VPN pour détection précoce.

7) « On a ajouté une route statique et maintenant autre chose a cassé »

Symptôme : Après des changements de route, des problèmes de reachabilité apparaissent entre VLANs.

Cause racine : Fuite de routes entre VRF ou routes plus spécifiques accidentelles faisant bypasser la politique pare‑feu.

Correctif : Gardez le routage simple ; documentez l’intention des routes ; utilisez des filtres de route ; vérifiez avec traceroute et compteurs pare‑feu.

Trois mini-récits d’entreprise tirés de la vie réelle

Mini-récit 1 : L’incident provoqué par une mauvaise hypothèse

Une entreprise de taille moyenne avait une « belle segmentation » : VLAN séparés pour utilisateurs, serveurs, management, VoIP et Wi‑Fi invité.
Les travailleurs distants se connectaient via VPN, recevaient une IP, et tout « fonctionnait ». On célébrait le succès.

L’hypothèse erronée était subtile : « les utilisateurs VPN sont essentiellement sur le VLAN utilisateur ». Ils ne l’étaient pas. Ils étaient sur un pool VPN que le pare‑feu traitait comme « LAN », parce que quelqu’un avait copié un jeu de règles existant des années auparavant.
Donc les clients VPN pouvaient router vers le VLAN de management, qui existait surtout parce que les auditeurs aimaient le diagramme.

Puis l’ordinateur d’un sous‑traitant a été infecté hors site. Rien de cinématographique — juste un infostealer commodity avec discovery réseau intégré.
Une fois connecté au VPN, le laptop a commencé à sonder. L’interface de management d’un hyperviseur a répondu. Puis un switch. Puis un appliance de sauvegarde avec une UI web.

L’issue n’a pas été un « apocalypse ransomware instantané », mais c’était quand même mauvais : la réutilisation d’identifiants s’est transformée en tentatives d’accès non autorisées, et le scanning bruyant a déclenché des alertes IDS que l’équipe n’avait jamais testées à ce volume.
La réponse incident s’est concentrée sur une question : « Pourquoi un utilisateur VPN peut‑il voir ça ? »

Le correctif a été presque ennuyeux : créer une zone VPN dédiée, default deny en forward, allowlister seulement les ports applicatifs nécessaires, et ajouter des refus explicites vers le management.
La partie embarrassante du postmortem : la segmentation existait sur papier, mais le VPN la contournait complètement.

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

Une autre organisation a décidé que le split tunneling était « non sécurisé », donc elle est passée à l’accès distant full‑tunnel.
Tout le trafic Internet des laptops distants était forcé via le pare‑feu du bureau, filtré, journalisé et NATé via un seul circuit ISP.

La première semaine semblait fine — parce que le déploiement a commencé avec un petit groupe pilote d’ingénieurs disciplinés qui utilisaient surtout SSH et outils internes.
La seconde semaine a inclus la direction commerciale, la visioconférence, et une pile d’onglets de navigateur qui streamaient tout, des vidéos de formation aux gros assets CRM.

Le pare‑feu n’a pas planté. Il est juste devenu le sablier le plus cher du monde. Le CPU a monté en softirq, le conntrack s’est approché du max, et la latence est devenue une conversation quotidienne.
Les utilisateurs ont commencé à activer/désactiver le VPN pour pouvoir travailler, ce qui a détruit le contrôle que l’équipe sécurité voulait.

Le retour de bâton n’était pas que le full‑tunnel soit toujours mauvais. C’est qu’ils l’ont traité comme un simple changement de politique, pas comme un changement d’architecture.
Ils n’avaient pas planifié la capacité, n’ont pas façonné le trafic, et n’ont pas défini ce que « Internet distant » devait laisser transiter.

La correction a été de revenir au split tunnel avec allowlists internes strictes et contrôles de posture endpoint, et un profil « voyage à risque élevé » séparé qui utilisait le full‑tunnel quand c’était réellement nécessaire.
Le grand gain a été culturel : l’organisation a cessé de croire qu’un mode VPN unique résout tout.

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

Une entreprise avec plusieurs VLAN et un VPN d’accès distant a fait quelque chose peu tendance : elle a maintenu une matrice vivante de « qui peut accéder à quoi », liée aux objets pare‑feu et aux groupes VPN.
Chaque demande de changement devait indiquer le service de destination, le port et le propriétaire métier. Pas de propriétaire, pas d’accès. Les gens se sont plaints. En silence.

Un matin, un VLAN serveur interne a commencé à voir des pics de trafic est‑ouest étranges. Pas énormes, mais constants.
Le monitoring a signalé de nouveaux schémas de connexion depuis le sous‑réseau VPN vers des plages serveur qui ne faisaient pas partie d’une liste d’accès approuvée.

L’astreinte n’a pas eu à deviner. Les journaux pare‑feu ont mappé l’IP source VPN à une identité utilisateur, les compteurs de refus montraient des blocages répétés vers un sous‑réseau de management, et la matrice d’accès montrait qu’il n’y avait aucune raison valide pour cet utilisateur d’être là.
Ils ont désactivé l’accès VPN de cet utilisateur et ont tourné quelques identifiants par précaution.

L’analyse ultérieure a suggéré un endpoint compromis. L’important : la segmentation et la journalisation ont maintenu le rayon d’action réduit et la détection précoce.
L’équipe n’a pas eu besoin d’actions héroïques. Il leur fallait la paperasserie ennuyeuse et la posture default‑deny que tout le monde avait levé les yeux.

Blague #2 : La matrice d’accès était si impopulaire qu’elle qualifie probablement comme une attaque par déni de service distribuée sur la patience des développeurs.

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

Étape 1 : Dessinez les segments qui comptent (pas ceux que vous souhaiteriez)

• Listez les VLANs et sous‑réseaux : utilisateurs, serveurs, management, imprimantes, IoT, invités, OT.
• Listez où le VPN termine : pare‑feu, routeur, passerelle Linux, cloud.
• Identifiez le(s) point(s) de routage inter‑VLAN et où la politique est appliquée.

Pression décisionnelle : Si le routage se fait en trois endroits, vous n’avez pas de segmentation — vous avez un puzzle.

Étape 2 : Choisissez le pool d’adresses client VPN comme si vous y viviez des années

• Utilisez une plage RFC1918 dédiée qui ne chevauche pas les réseaux domestiques courants.
• Faites‑la assez grande pour la croissance (ne vous enfermez pas dans un /24 si vous aurez 800 utilisateurs).
• Documentez‑la comme zone de sécurité : « VPN-Users ».

Étape 3 : Définissez l’accès par rôle et service

• Groupez les utilisateurs selon leurs besoins : dev, finance, IT, fournisseurs, support.
• Pour chaque groupe : énumérez les destinations (sous‑réseaux/hôtes) et les ports.
• Privilégiez les destinations au niveau service (VIPs, load balancers) plutôt que des sous‑réseaux entiers.

Étape 4 : Implémentez « le moins de routes » plus « le moins de règles pare‑feu »

• Pushez seulement les routes nécessaires à chaque groupe.
• Refus par défaut entre zone VPN et zones internes.
• Allowlistez les ports avec justification et contrôle de changement.
• Bloquez explicitement les réseaux de management et l’est‑ouest sensible par défaut.

Étape 5 : Rendre le DNS et l’heure cohérents

• Définissez intentionnellement les serveurs DNS VPN et les domaines de recherche internes.
• Assurez‑vous que NTP est joignable ; l’authentification et les journaux dépendent du temps.
• Décidez split DNS vs recursion interne complète selon la politique.

Étape 6 : Journalisation et audit qui ne vous embarrasseront pas plus tard

• Journalisez les événements d’authentification VPN avec identité utilisateur et IP assignée.
• Journalisez les refus pare‑feu depuis la zone VPN (au moins initialement).
• Conservez assez de données pour répondre à « qui a accédé quoi » pour vos besoins conformité.

Étape 7 : Testez comme un pessimiste

• Tests positifs : applis requises joignables depuis le VPN.
• Tests négatifs : VLAN de management injoignable ; VLAN utilisateur injoignable (sauf si requis).
• Tests de performance : MTU, débit, concurrence, basculement.

Étape 8 : Faites fonctionner sans transformer chaque changement en état d’alerte

• Mettez les règles pare‑feu et la config VPN en contrôle de version.
• Ayez un plan de rollback qui ne requiert pas « la seule personne qui sait ».
• Utilisez des déploiements par étapes pour les changements de politique.

FAQ

1) Les clients VPN doivent‑ils être dans le même VLAN/sous‑réseau que les utilisateurs du bureau ?

Non. Donnez aux clients VPN leur propre sous‑réseau routé (ou zone équivalente VLAN) et appliquez une politique plus stricte.
Si vous avez besoin de la « même expérience », résolvez‑le par le DNS et l’accès autorisé, pas par l’adjacence couche‑2 partagée.

2) Le split tunneling est‑il peu sûr ?

Le split tunneling est un compromis. Il réduit la charge et la latence, mais suppose que les endpoints sont raisonnablement gérés.
Si vous ne pouvez pas faire confiance aux endpoints, le full‑tunnel n’est pas une solution magique — les attaquants montent toujours par l’endpoint. Utilisez des checks de posture et des allowlists internes strictes dans les deux cas.

3) Pourquoi ne pas simplement autoriser les utilisateurs VPN à atteindre des VLAN serveurs entiers ?

Parce que vous donnez la capacité de reconnaissance et de mouvement latéral. Cela augmente aussi le rayon d’action en cas de compromis d’un endpoint.
Si les utilisateurs ont besoin « d’une appli », autorisez cette appli (VIP, port). S’ils ont besoin « d’un sous‑réseau entier », demandez pourquoi, puis rendez‑le limité dans le temps et journalisé.

4) Quelle est la façon la plus propre de bloquer l’accès VPN aux réseaux de management ?

Placez le management dans des subnets/VLAN dédiés et ajoutez des refus explicites depuis la zone VPN vers ces subnets.
N’annoncez pas non plus les routes vers ces subnets aux clients VPN sauf si un profil admin en a besoin.

5) Les VLAN seuls fournissent‑ils une segmentation sécurisée ?

Les VLAN fournissent une séparation en couche 2. Sans routage contrôlé et politique de pare‑feu, ce ne sont pas des frontières de sécurité.
Supposez que toute adjacence routée sans politique est un « peut‑être plus tard » chemin de brèche.

6) Comment gérer le chevauchement d’espace IP entre utilisateurs distants et VLAN du bureau ?

Le mieux : évitez les chevauchements via une planification d’adressage corporative sensée (n’utilisez pas les plages domestiques communes).
Si vous héritez du problème, dernier recours : NAT pour les clients VPN ou renumérotation. Le NAT fonctionne mais complique identité, journalisation et certains protocoles.

7) Pourquoi je vois des états SYN‑RECV quand des utilisateurs VPN se connectent à des services internes ?

Souvent routage asymétrique : le serveur renvoie via un routeur différent de celui qui a vu le SYN. Les pare‑feu stateful laissent alors tomber le trafic de retour.
Corrigez la route de retour pour qu’elle repasse par la passerelle VPN/pare‑feu, ou assurez‑vous que le pare‑feu voit les deux directions.

8) Dois‑je router le trafic inter‑VLAN sur le switch core ou sur le pare‑feu ?

Pour la performance pure, les switches excellent. Pour la segmentation sécurisée avec pistes d’audit, les pare‑feu sont meilleurs.
Beaucoup d’environnements font les deux : commutation pour le routage basique, pare‑feu comme point d’application avec politiques de zones explicites.

9) Comment prouver que la segmentation fonctionne ?

Faites des tests négatifs depuis des clients VPN (tentatives d’accès au sous‑réseau de management, scan de ports bloqués), vérifiez que les compteurs/journaux du pare‑feu montrent des drops, et documentez les refus attendus.
Une segmentation que vous ne pouvez pas tester n’est qu’une histoire architecturale pour la nuit.

Conclusion : prochaines étapes sans faire fondre votre réseau

Le VPN de bureau plus la segmentation VLAN n’est pas difficile à cause de la technologie. C’est difficile parce que « faire fonctionner » est facile, et « rendre sûr, limité et maintenable » demande de la discipline.
La bonne nouvelle : la discipline tient principalement à l’étendue des routes, la politique default‑deny, et des journaux que vous pouvez réellement utiliser.

Prochaines étapes exécutables cette semaine :

• Créez un sous‑réseau/zone dédiés pour les utilisateurs VPN et arrêtez de le traiter comme le « LAN ».
• Inventoriez quels services internes les utilisateurs distants ont vraiment besoin (destinations + ports), puis implémentez des allowlists.
• Retirez les pushes de routes larges ; annoncez seulement les sous‑réseaux nécessaires par groupe.
• Exécutez le guide de diagnostic rapide sur une appli « connue pour être capricieuse » et corrigez MTU/routes de retour avant que ça ne devienne culturel.
• Activez la journalisation qui mappe les IP VPN aux identités et conservez‑la assez longtemps pour répondre aux questions gênantes.

Vous n’avez pas besoin d’un réseau plat pour être productif. Vous avez besoin d’un réseau où l’accès est intentionnel — et où les modes d’échec sont prévisibles, pas mystérieux.