Accès par groupes via un seul VPN : Comptabilité, Entrepôt, IT, droits distincts

Le modèle : un VPN, de multiples droits

« Un VPN » ne signifie pas « un seul niveau de confiance ». Cela signifie un point d’entrée et une surface opérationnelle : une expérience de profil client,
un flux de support, un endroit pour faire tourner les clés et certificats. Les droits sont calculés après l’authentification et appliqués sur le chemin
vers la destination. Pensez-y comme un aéroport : tout le monde entre dans le bâtiment, mais tout le monde n’accède pas au cockpit.

Pour la comptabilité, « droits » signifie généralement accès à l’ERP, aux partages financiers et peut‑être un jump host vers un serveur de terminal. Pour l’entrepôt,
il s’agit typiquement du WMS, d’applications sur terminaux de codes-barres, d’imprimantes, peut‑être d’un dépôt de fichiers limité. Pour l’IT, ce sont les réseaux d’administration,
interfaces de gestion, sauvegardes, hyperviseurs, et l’autorité de « casser la vitre » quand tout brûle.

Vous obtenez un accès fiable basé sur les groupes en combinant quatre primitives :

• Identité forte : qui est cet utilisateur/appareil, et quel est notre degré de certitude ?
• Adhésion au groupe : quel(s) rôle(s) ont‑ils en ce moment ?
• Politique : à quoi ce rôle est‑il autorisé à accéder (réseaux, ports, applis, partages).
• Application : où cette politique est réellement appliquée (pare‑feu, routage, ACL stockage, authentification applicative).

Si vous ne faites qu’une couche, vous serez déçu. Si vous en faites deux, vous dormirez mieux. Si vous en faites trois ou quatre,
vous cesserez d’avoir des débats philosophiques sur « sécurité vs productivité » parce que le système sera les deux.

Idée paraphrasée (attribuée) : Les systèmes qui doivent être fiables doivent partir du principe que les choses échoueront et concevoir pour cette réalité — John Allspaw.
Le VPN et ses politiques ne font pas exception.

Blague n°1 : Un VPN sans contrôles d’accès, c’est comme une boîte de nuit avec un videur et aucune liste — tout le monde entre, et le DJ finit par gérer les incidents.

Faits intéressants & contexte historique

• Les VPN ont commencé comme des « tuyaux sécurisés », pas comme des systèmes d’identité. La pensée IPsec initiale privilégiait le tunnel ; l’autorisation était souvent après coup.
• Le split tunneling est controversé depuis son adoption. C’est un compromis de sécurité : moins de backhaul, plus de risque si les endpoints sont sales.
• RADIUS précède la plupart des flux UI VPN modernes. L’autorisation basée sur des groupes via les attributs RADIUS existe depuis des décennies.
• La prolifération de groupes dans Active Directory est un mode d’échec prévisible. Les groupes « accès temporaire » finissent souvent colocataires permanents.
• La segmentation réseau était autrefois majoritairement physique. Les VLANs et VRF l’ont rendue logique ; la politique VPN moderne la rend pilotée par l’identité.
• Les permissions SMB et POSIX ont évolué séparément. Quand vous mélangez Samba + ACL Linux + groupes Windows, les malentendus sont garantis.
• « Zero Trust » est un nouveau label pour de vieux principes. Le moindre privilège, l’authentification forte et la journalisation n’ont pas été inventés en 2019 ; le marketing s’est juste amélioré.
• WireGuard est jeune mais volontairement opinionné. Il évite intentionnellement l’authentification utilisateur intégrée ; vous devez intégrer l’identité ailleurs.
• Les exigences d’audit façonnent discrètement l’architecture. Si vous ne pouvez pas répondre « qui a accédé à quoi », votre conception sera réécrite par la conformité plus tard.

Architecture de référence qui tient la route

Choisissez un plan de contrôle, puis respectez‑le

La façon la plus rapide de construire un VPN fragile est de laisser chaque couche inventer sa propre notion de « groupe ».
Votre serveur VPN a des « configs client », votre pare‑feu a des « objets d’adresse », votre NAS a des « utilisateurs locaux »,
et vos auditeurs ont des « questions ». Ne faites pas cela.

Choisissez une source d’identité unique de vérité :

• Active Directory (AD) si vous êtes déjà dans un environnement Windows.
• LDAP/FreeIPA si vous voulez une identité native Linux solide.
• Un fournisseur d’identité + SSO si vous modernisez, mais soyez réaliste quant à la complexité opérationnelle.

Points d’application : où la politique devient réelle

La conception propre utilise plusieurs points d’application, chacun faisant ce qu’il sait bien faire :

• Passerelle VPN : authentification, attribution d’IP, poussée de routes/DNS, politique grossière par groupe.
• Pare‑feu/gateway de segmentation : accès réseau au moindre privilège (ports, destinations) avec journaux auditables.
• Contrôles applicatifs : ERP/WMS/SSH ont leurs propres authentifications ; utilisez‑les.
• Contrôles de stockage : ACL Samba/NTFS, ACL NFSv4, S3/IAM, délégation de dataset ZFS — ce qui convient, mais appliquez‑les.

La passerelle VPN n’est pas un appareil magique de politique. C’est un point d’étranglement. Utilisez‑la pour garantir que les identités correspondent aux IP et routes attendues.
Puis faites du pare‑feu la source de vérité pour « qui peut parler à quoi ».

Un agencement concret et adapté à la production

Voici un agencement qui évolue bien et ne se transforme pas en maison hantée :

• Une seule entrée VPN : vpn-gw01 (et vpn-gw02 pour HA si vous tenez aux weekends).
• Secteurs internes séparés derrière une frontière pare‑feu/VRF :
  • FIN-NET (apps comptabilité, partages financiers)
  • WMS-NET (serveurs d’applications entrepôt, imprimantes)
  • MGMT-NET (hyperviseurs, iDRAC/iLO, serveurs de sauvegarde)
  • USER-NET (services généraux corp)
• Pools d’adresses VPN par groupe (ou par rôle), ex. :
  • 10.66.10.0/24 pour la comptabilité
  • 10.66.20.0/24 pour l’entrepôt
  • 10.66.30.0/24 pour l’IT
• Règles pare‑feu indexées sur le pool source VPN plus journaux d’identité depuis l’auth VPN.
• DNS par groupe : les utilisateurs finance ne devraient pas résoudre les noms mgmt, non pas parce que le DNS est « sécurité », mais parce que c’est de l’hygiène et que ça réduit les erreurs.

Vous remarquerez le schéma : isoler par défaut, autoriser de façon étroite, et rendre la preuve facile.

Identité et mappage de groupes : où commence le contrôle d’accès

Utilisateurs vs appareils : décidez ce que vous autorisez

Les environnements d’entrepôt ont souvent des appareils partagés, des connexions kiosque ou des scanners embarqués.
La comptabilité tend à avoir des utilisateurs nominatifs avec une sensibilité plus élevée. L’IT a souvent des utilisateurs nominatifs et des appareils privilégiés.

Décidez, explicitement :

• VPN basé utilisateur : l’utilisateur s’authentifie avec MFA ; l’appartenance au groupe est dérivée des groupes d’annuaire.
• VPN basé appareil : certificat appareil ou clé pré‑partagée ; le groupe est dérivé de l’identité de l’appareil.
• Hybride : l’appareil doit être inscrit et l’utilisateur doit s’authentifier (idéal pour l’accès admin IT).

Si vous ne pouvez pas dire si vos lecteurs de codes‑barres d’entrepôt sont « utilisateurs » ou « appareils », vous êtes sur le point de construire la mauvaise politique.

Mappage de groupes : restez ennuyeux

Utilisez un petit nombre de « groupes d’accès » qui correspondent à des ensembles de politiques réseau, pas à des organigrammes.
Les groupes organisationnels changent avec les réorganisations et la politique. Les groupes d’accès doivent changer avec les besoins applicatifs.

Schéma pratique :

• VPN-Accounting → apps FIN + partages financiers
• VPN-Warehouse → app WMS + imprimantes
• VPN-IT → réseaux mgmt + jump hosts + SSH/RDP vers serveurs
• VPN-AllUsers → baseline minimal (DNS, NTP, gestion des endpoints)

MFA : faites‑le, mais sans posture de façade

MFA n’est pas une politique. C’est une butée qui aide lorsque des identifiants fuient.
Vous avez encore besoin de contrôles d’autorisation parce qu’un attaquant avec un token de session compromis se moque de vos posters motivationnels.

Couches d’application : routage, pare-feu et stockage

Routage : contrôlez le rayon d’explosion avec des pools d’adresses et la poussée de routes

Attribuez des pools VPN séparés par groupe. C’est le levier le plus simple et le plus favorable pour l’audit que vous avez.
Cela rend le pare‑feu simple et rend les enquêtes « qui a fait ça » moins ésotériques.

La poussée de routes doit être minimale :

• Les clients compta reçoivent des routes uniquement vers FIN-NET et les services partagés réellement nécessaires.
• Les clients entrepôt reçoivent des routes uniquement vers WMS-NET et les sous‑réseaux d’imprimantes.
• Les clients IT peuvent obtenir des routes plus larges, mais privilégiez les jump hosts pour les surfaces d’administration.

Si vous êtes tenté de « pousser 0.0.0.0/0 à tout le monde » pour simplifier : ce n’est pas de la simplicité, c’est de la dette.

Pare‑feu : l’adulte dans la pièce

La politique pare‑feu doit être explicite, journalisée et sous contrôle de changement.
Préférez des listes d’autorisation par groupe. Refus par défaut. Journalisez les refus pour le débogage (mais limitez le rythme pour ne pas DDoS votre SIEM).

Une structure de règles solide :

• Source : pool VPN (10.66.10.0/24)
• Destination : sous‑réseau d’application ou groupe d’hôtes
• Service : TCP/443, TCP/445, UDP/161, etc.
• Action : allow + log (au moins pour les réseaux admin)

Permissions de stockage : là où « accès réseau » ne suffit pas

Les données financières ne sont pas protégées parce qu’elles sont sur FIN-NET. Elles sont protégées par le serveur de fichiers qui applique les permissions.
Si un utilisateur entrepôt peut monter un partage SMB et parcourir des dossiers de compta, votre segmentation réseau est décorative.

Faites‑le correctement :

• Samba/SMB : utilisez des ACL AD ; mappez les groupes proprement ; évitez les utilisateurs locaux sur le NAS pour les partages d’entreprise.
• NFSv4 : préférez les ACL NFSv4 avec identité liée aux répertoires ; ne comptez pas sur des conjectures d’UID.
• Datasets ZFS : datasets séparés par classe de sensibilité ; snapshots ; délégation pour les opérations IT sans accès aux données lorsque possible.

Blague n°2 : Si votre « politique d’accès » est un tableur et de l’espoir, félicitations — vous avez inventé le Théâtre de la Conformité : La Comédie Musicale.

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

Voici les tâches que vous lancez réellement lorsque vous construisez ou déboguez un accès par groupes via un seul VPN.
Chaque tâche comprend : une commande, ce que signifie une sortie typique, et la décision que vous prenez.
Les noms d’hôtes et chemins sont réalistes ; adaptez‑les à votre environnement.

1) Confirmer que l’interface VPN est montée et a le bon pool d’adresses

cr0x@server:~$ ip -brief addr show dev wg0
wg0             UNKNOWN        10.66.0.1/16

Signification : L’interface de passerelle existe et a le supernet attendu. Si vous vouliez des pools /24 séparés,
la passerelle peut encore utiliser un préfixe plus grand ; c’est acceptable tant que les règles pare‑feu se basent sur l’IP source client.

Décision : Si l’interface manque ou que l’IP est incorrecte, arrêtez‑vous et corrigez la mise en route/config du VPN avant de chasser les « permissions ».

2) Vérifier les pairs VPN actifs et leurs adresses attribuées

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

peer: Zq1a...redacted
  endpoint: 198.51.100.24:53321
  allowed ips: 10.66.10.23/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 102.45 MiB received, 88.22 MiB sent

Signification : Ce pair utilise 10.66.10.23, ce qui doit correspondre à un groupe (ici : pool comptabilité).
Un handshake récent confirme que le tunnel est vivant.

Décision : Si un utilisateur entrepôt apparaît dans la plage compta, la logique d’attribution identité→IP est cassée.
Corrigez cela avant de bricoler les règles pare‑feu ; sinon vous « corrigerez » en ouvrant des trous.

3) Vérifier le routage pour un sous‑réseau protégé depuis la passerelle VPN

cr0x@server:~$ ip route get 10.20.10.50
10.20.10.50 via 10.0.0.1 dev eth0 src 10.0.0.10 uid 1000

Signification : La passerelle sait comment atteindre FIN-NET (exemple hôte 10.20.10.50). Si c’est incorrect, les clients peuvent s’authentifier mais ne pourront rien atteindre.

Décision : Si la route pointe ailleurs (ou manque), corrigez le routage interne/VRF avant d’accuser les utilisateurs VPN.

4) Confirmer le forwarding IP sur la passerelle (classique « ça connecte mais rien ne marche »)

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

Signification : La passerelle peut router le trafic entre interfaces.

Décision : Si c’est 0, activez‑le (et persistez la valeur) avant de déboguer les règles pare‑feu.

5) Inspecter les règles nftables qui filtrent les pools VPN

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ip saddr 10.66.10.0/24 ip daddr 10.20.10.0/24 tcp dport { 443, 445 } accept
    ip saddr 10.66.20.0/24 ip daddr 10.30.20.0/24 tcp dport 443 accept
    ip saddr 10.66.30.0/24 ip daddr 10.40.0.0/16 accept
    counter drop
  }
}

Signification : Refus par défaut. Puis autorisations explicites par pool VPN. Voilà à quoi ressemble « droits distincts » en pratique.

Décision : Si la comptabilité peut atteindre l’entrepôt ou les réseaux mgmt, vous trouverez probablement une règle allow trop large ou une plage source inattendue.

6) Valider que le pare‑feu journalise le refus qui vous intéresse

cr0x@server:~$ sudo journalctl -k -n 20 | grep -E "DROP|DENY" | tail
Dec 28 11:04:02 vpn-gw01 kernel: IN=wg0 OUT=eth0 SRC=10.66.20.44 DST=10.20.10.50 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=39321 DF PROTO=TCP SPT=51522 DPT=445 WINDOW=64240 SYN

Signification : Un client entrepôt a tenté d’atteindre SMB sur un serveur finance, et cela a été bloqué. Bien. C’est l’application de la politique qui fait son travail.

Décision : Si vous ne voyez pas de journaux, soit les paquets n’atteignent pas la passerelle (routage), soit la journalisation n’est pas activée (débogage plus difficile).

7) Confirmer quelle IP un utilisateur a réellement (côté client)

cr0x@server:~$ ip -brief addr show dev wg0
wg0             UNKNOWN        10.66.20.44/32

Signification : Le client est dans le pool entrepôt. C’est votre premier contrôle de cohérence quand quelqu’un dit « Je suis en compta mais je ne peux pas joindre finance. »

Décision : Si l’IP ne correspond pas au pool attendu, corrigez le mappage de groupes ou l’affectation de profil, pas le pare‑feu.

8) Tester la connectivité vers un service autorisé (TCP/443) et interpréter les modes d’échec

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

Signification : Le chemin réseau et l’autorisation pare‑feu pour ce service sont corrects.

Décision : Si ça time‑out, c’est généralement routage/pare‑feu. Si c’est « refused », l’hôte est joignable mais le service n’écoute pas ou est bloqué localement.

9) Tracer le chemin quand le routage est bizarre (surtout avec plusieurs sauts internes)

cr0x@server:~$ traceroute -n 10.20.10.50
traceroute to 10.20.10.50 (10.20.10.50), 30 hops max, 60 byte packets
 1  10.66.0.1  9.214 ms  9.012 ms  9.118 ms
 2  10.0.0.1   10.202 ms  10.144 ms  10.165 ms
 3  10.20.10.50  11.011 ms  10.989 ms  10.972 ms

Signification : Vous voyez la passerelle VPN, puis le routeur/pare‑feu interne, puis la destination. C’est le chemin heureux.

Décision : Si ça meurt au saut 1, c’est local client/VPN. Si ça meurt au saut 2, c’est routage/pare‑feu interne.

10) Vérifier le comportement DNS par groupe (parce que « je ne peux pas joindre l’ERP » est souvent « mauvaise résolution de nom »)

cr0x@server:~$ resolvectl status wg0
Link 12 (wg0)
      Current Scopes: DNS
DefaultRoute setting: no
       LLMNR setting: no
MulticastDNS setting: no
  DNS Servers: 10.20.10.53
   DNS Domain: corp.example

Signification : Le DNS pour l’interface VPN pointe vers le serveur DNS finance (exemple). Si les utilisateurs entrepôt ne doivent pas utiliser ce DNS,
il ne devrait pas leur être poussé.

Décision : Si le mauvais DNS est appliqué, corrigez le DNS poussé par le VPN ou la config client ; n’« ouvrez » pas le pare‑feu à des résolveurs aléatoires.

11) Confirmer l’appartenance au groupe AD d’un utilisateur (entrée d’autorisation)

cr0x@server:~$ id jsmith
uid=11820(jsmith) gid=10513(domain users) groups=10513(domain users),12900(VPN-Warehouse),12910(WMS-Users)

Signification : Cet utilisateur est dans VPN-Warehouse et devrait se voir attribuer la politique d’accès entrepôt.

Décision : Si l’utilisateur n’a pas le groupe VPN attendu, corrigez l’appartenance dans l’annuaire et réauthentifiez ; n’ajoutez pas d’exceptions dans le pare‑feu.

12) Inspecter les ACL de partage Samba (application de stockage)

cr0x@server:~$ getfacl /srv/samba/finance
# file: srv/samba/finance
# owner: root
# group: "CORP\\Finance Admins"
user::rwx
group::rwx
group:"CORP\\Accounting":rwx
group:"CORP\\Warehouse":---
mask::rwx
other::---

Signification : L’entrepôt n’a aucune permission. La comptabilité en a. Voilà à quoi ressemble « droits distincts » là où vivent les données.

Décision : Si l’entrepôt peut lire la finance malgré tout, vous avez probablement un autre chemin de partage, des ACL héritées, ou une mauvaise configuration de mapping SMB guest.

13) Confirmer que SMB voit le bon mapping d’identité (classique « permissions correctes mais accès erroné »)

cr0x@server:~$ wbinfo -i jsmith
jsmith:*:11820:10513:John Smith:/home/CORP/jsmith:/bin/bash

Signification : Winbind peut mapper l’utilisateur AD à une identité Unix. Si cela échoue, les ACL qui référencent des groupes AD ne fonctionneront pas.

Décision : Corrigez l’intégration d’annuaire (Kerberos, winbind, SSSD) avant de toucher aux ACL.

14) Prouver quel côté abandonne les paquets avec tcpdump (à utiliser parcimonieusement, mais utilisez‑le)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.66.10.23 and host 10.20.10.50 and tcp port 445 -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
11:06:41.112233 IP 10.66.10.23.51422 > 10.20.10.50.445: Flags [S], seq 11223344, win 64240, options [mss 1380,sackOK,TS val 12345 ecr 0,nop,wscale 7], length 0
11:06:42.114512 IP 10.66.10.23.51422 > 10.20.10.50.445: Flags [S], seq 11223344, win 64240, options [mss 1380,sackOK,TS val 13345 ecr 0,nop,wscale 7], length 0

Signification : Les SYN arrivent sur l’interface VPN ; si aucun SYN-ACK ne revient, le drop est en aval (pare‑feu, routage, pare‑feu hôte, service).

Décision : Si vous voyez du trafic sur wg0 mais pas sur eth0, le pare‑feu de la passerelle bloque. Si vous le voyez aussi sur eth0, c’est en aval.

15) Vérifier conntrack pour l’état (surtout avec routage asymétrique)

cr0x@server:~$ sudo conntrack -L | grep 10.66.10.23 | head
tcp      6 117 SYN_SENT src=10.66.10.23 dst=10.20.10.50 sport=51422 dport=445 src=10.20.10.50 dst=10.66.10.23 sport=445 dport=51422 [UNREPLIED] mark=0 use=1

Signification : La passerelle voit la tentative sortante, mais ne reçoit pas de réponses. Cela réduit considérablement la zone à inspecter.

Décision : Allez vérifier les politiques du pare‑feu interne, les routes de retour, et le pare‑feu hôte sur 10.20.10.50.

16) Valider les routes de retour sur un serveur interne (classique « marche depuis le LAN, pas depuis le VPN »)

cr0x@server:~$ ip route
default via 10.20.10.1 dev eth0
10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.50

Signification : La gateway par défaut du serveur est 10.20.10.1. Si les clients VPN viennent de 10.66.0.0/16 et que 10.20.10.1 ne sait pas comment retourner,
les réponses peuvent être perdues.

Décision : Assurez‑vous que la passerelle interne connaît les routes vers les pools VPN (ou SNAT sur la passerelle VPN — dernier recours, mais parfois opérationnellement sensé).

Guide de diagnostic rapide

Quand un utilisateur dit « le VPN est en panne », il veut dire cinq choses différentes. Votre travail est de trouver le goulot en minutes, pas en heures.
Voici l’ordre qui fonctionne en production.

Première étape : identifier la portée et classer la panne

• Un utilisateur vs un groupe vs tout le monde.
• Échec d’authentification vs connecté mais impossible d’atteindre vs peut atteindre mais pas de permissions.
• Une appli vs toutes les destinations internes.

Si c’est tout le monde : stop. Vous regardez la santé de la passerelle, les certificats/clés, le routage ou une panne en amont.
Si c’est un groupe : suspectez le mappage de groupe, l’affectation du pool d’adresses, l’ordre des règles pare‑feu, ou la poussée de routes.
Si c’est un utilisateur : suspectez l’identité (appartenance au groupe), la config client, ou les contrôles posture de l’appareil.

Deuxième étape : vérifier le tunnel et l’IP attribuée

• Sur la passerelle : wg show / fichier status OpenVPN / état SA IPsec.
• Sur le client : IP de l’interface et paramètres DNS.

Une mauvaise plage IP signifie de mauvais droits. Ce n’est pas un « bug réseau », c’est un bug de mappage d’autorisation.

Troisième étape : tester un flux autorisé bout en bout

• Choisissez une destination connue‑bonne pour ce groupe (ex. : entrepôt → WMS HTTPS).
• Testez avec nc ou curl plutôt que « ouvrir un navigateur et espérer ».
• Regardez les journaux de refus du pare‑feu pendant le test.

Quatrième étape : localiser l’endroit du drop

• La passerelle voit‑elle le paquet sur l’interface VPN ?
• La passerelle forwarde‑t‑elle le paquet sur l’interface LAN ?
• Le pare‑feu interne le voit‑il et l’autorise‑t‑il ?
• L’hôte de destination répond‑il ?

Cinquième étape : ne touchez les permissions de stockage qu’après

Si le réseau n’atteint pas le serveur de fichiers, les permissions n’ont pas d’importance.
Si le réseau atteint le serveur mais l’accès est refusé, vous êtes alors en territoire ACL (journaux Samba, permissions effectives, mappage de groupes).

Erreurs courantes : symptômes → cause racine → correction

1) « L’entrepôt voit les partages finance »

Symptômes : Un utilisateur entrepôt peut parcourir ou lire des partages SMB finance après connexion VPN.

Cause racine : La segmentation réseau existe, mais le chemin des partages finance est accessible depuis un VLAN serveur de fichiers général ; héritage ACL ou permissions « Everyone »/« Domain Users » ont fuité.

Correction : Placez les partages finance sur un dataset/partage dédié avec absence explicite ou refus pour les groupes entrepôt ; vérifiez avec getfacl et des contrôles d’accès effectifs SMB ; restreignez les chemins réseau pour que seul le pool compta puisse atteindre TCP/445 sur les serveurs finance.

2) « La compta n’arrive pas à joindre l’ERP, mais ping fonctionne »

Symptômes : ICMP réussit ; la connexion applicative échoue ou time‑out.

Cause racine : Le pare‑feu autorise ICMP (ou il n’est pas filtré) mais bloque TCP/443 ou le port de l’appli ; parfois des problèmes de MTU provoquent des blocages TLS.

Correction : Testez avec nc -vz sur le port exact ; vérifiez les règles pare‑feu pour le pool compta ; si TLS bloque, testez la MTU (ping -M do -s) et clamperez MSS sur la passerelle.

3) « L’IT peut atteindre les serveurs, mais SSH gèle aléatoirement »

Symptômes : TCP se connecte, puis les sessions se figent de façon intermittente, surtout sur réseaux mobiles.

Cause racine : PMTUD bloqué, causant des problèmes de fragmentation ; ou pression sur la table conntrack sous charge.

Correction : Activez le clamp MSS sur la passerelle ; vérifiez l’utilisation de conntrack et augmentez les limites si justifié ; assurez‑vous que l’ICMP « fragmentation needed » n’est pas bloqué en interne.

4) « L’utilisateur a été déplacé vers compta, il conserve l’accès entrepôt »

Symptômes : Le changement de groupe dans l’annuaire a été fait, mais les droits VPN restent inchangés pendant des heures.

Cause racine : L’appartenance au groupe est mise en cache par la couche d’auth VPN (cache RADIUS/LDAP) ou les sessions VPN longue durée ne forcent pas la réauth.

Correction : Réduisez le TTL du cache d’auth, forcez la réauthentification sur changement de groupe, définissez des durées de session ; opérationnellement : ayez un runbook « droits changés → déconnecter la session ».

5) « Tout le monde obtient des routes complètes malgré la config par groupe »

Symptômes : Les clients entrepôt voient des routes internes qu’ils ne devraient pas ; traceroute va où il ne faut pas.

Cause racine : La config client par défaut pousse des routes larges ; les overrides par groupe ne sont pas appliqués ou l’ordre est incorrect.

Correction : Rendez la poussée de routes explicite par groupe et testez avec un profil client propre ; traitez les configs clients comme du code, avec revue et déploiement progressif.

6) « VPN connecté, mais DNS résout des noms internes en IP publiques »

Symptômes : Les utilisateurs atteignent les mauvais endpoints ; SSO boucle ; erreurs applicatives qui ressemblent à des échecs d’auth.

Cause racine : DNS splitté non configuré ; le client utilise toujours des résolveurs publics/maison ; search domains non définis.

Correction : Poussez les bons serveurs DNS et domaines par groupe ; vérifiez avec resolvectl ; évitez de compter sur des réglages DNS manuels sur les endpoints.

7) « L’accès marche un moment puis casse après des changements réseau »

Symptômes : Après l’ajout d’un nouveau sous‑réseau ou le déplacement d’une appli, un groupe perd l’accès tandis que les autres restent corrects.

Cause racine : Objets/groupes pare‑feu non mis à jour ; route non annoncée ; dérive des politiques entre environnements.

Correction : Maintenez une source unique de vérité pour sous‑réseaux et politiques ; ajoutez des hooks de changement : quand un sous‑réseau est introduit, mettez à jour les routes poussées et les règles pare‑feu ensemble, puis validez avec des tests de connectivité.

8) « Un utilisateur finance ne peut pas ouvrir des feuilles SMB, mais peut lister les dossiers »

Symptômes : Le listing de répertoire fonctionne ; l’ouverture de fichier échoue avec des erreurs de permissions ou de verrouillage.

Cause racine : Permissions au niveau des fichiers NTFS/Samba incorrectes ; ou incompatibilité des exigences SMB signing/encryption ; parfois les paramètres d’opportunistic locking gênent les anciens clients.

Correction : Vérifiez les ACLs fichier et l’héritage, pas seulement le dossier racine ; vérifiez la config Samba ; testez avec un client Windows connu‑bon ; gardez la sécurité SMB cohérente.

Trois mini-récits de la vie en entreprise

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

Une entreprise de taille moyenne a consolidé l’accès distant dans un seul VPN « pour simplifier le support ». Objectif sensé.
L’équipe réseau a découpé des pools VPN séparés pour compta et entrepôt et a considéré le travail terminé. Toujours sensé — sur le papier.
Puis un chef d’entrepôt ouvre un ticket : « Je vois des dossiers finance. C’est normal ? »

L’hypothèse était que si l’entrepôt ne pouvait pas router vers FIN-NET, il ne pouvait pas accéder aux données finance.
Malheureusement, les partages finance n’étaient pas sur FIN-NET. Ils vivaient sur un serveur de fichiers à usage général accessible depuis USER-NET,
parce que « ce ne sont que des fichiers » et que le serveur existait avant le projet de segmentation.
La segmentation réseau et le placement des données avaient dérivé comme deux collègues qui ont cessé de se parler après une réorganisation.

La correction immédiate fut moche mais efficace : règle pare‑feu bloquant TCP/445 depuis le pool entrepôt vers le serveur de fichiers.
Cela arrêta l’hémorragie mais cassa aussi des dépôts légitimes de l’entrepôt, car ils étaient sur le même serveur.
La vraie correction prit une semaine : créer des partages Samba séparés soutenus par des datasets ZFS distincts, déplacer les données finance vers un dataset dédié,
et appliquer des ACLs basées sur AD. Le partage entrepôt resta accessible, finance non.

La leçon n’était pas « la segmentation réseau est mauvaise ». La leçon est que la segmentation sans application sur le stockage n’est qu’une suggestion,
et les attaquants aiment les suggestions.

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

Ailleurs, une « idée intelligente » : réduire la CPU du serveur VPN et simplifier le routage en SNATant tout le trafic client VPN vers une IP gateway unique.
L’argument était performance et simplicité : moins de routes internes, moins d’état dispersé sur l’infrastructure pare‑feu.
Ça a « marché », au sens où un mur fraîchement peint « marche » pour cacher une fissure.

Puis arriva la saison d’audit. L’équipe sécurité posa une question simple : « Quels utilisateurs ont accédé au sous‑réseau applicatif finance mardi dernier ? »
Avec le SNAT, les logs internes ne montraient que l’IP de la passerelle. Les logs VPN contenaient les identités, certes, mais corréler par‑flux nécessitait d’assembler
horaires de session et conjectures sur quel trafic appartenait à quel utilisateur. C’était possible, mais indéfendable.

Opérationnellement, le SNAT empirait le débogage. Quand l’appli WMS ralentit, les équipes applicatives blâmaient le VPN.
L’équipe VPN blâmait l’appli. L’équipe pare‑feu n’avait qu’une IP source pour tout le monde, donc elle ne pouvait pas isoler des clients bruyants ni voir un comportement par groupe.
Le système perdit en observabilité, et chaque incident prit plus de temps car la vérité devait être reconstituée.

Ils ont finalement annulé le SNAT et ajouté des routes de retour correctes depuis les réseaux internes vers les pools VPN.
La CPU monta un peu ; la clarté monta beaucoup. C’est généralement un bon compromis.

Mini‑récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une entreprise avec une séparation stricte entre compta et entrepôt avait une pratique qui semblait douloureusement ennuyeuse : des « vérifications de réalité d’accès » trimestrielles.
Pas un exercice annuel pour cocher une case. Trimestriel. Un petit ensemble de tests scriptés s’exécutait depuis trois comptes tests — un par groupe — et vérifiait la reachabilité :
la compta peut‑elle atteindre l’ERP ? l’entrepôt peut‑il atteindre le WMS ? l’IT peut‑il atteindre les jump hosts ? l’entrepôt ne peut‑il pas atteindre le SMB finance ?

Un vendredi, une mise à jour réseau interne a déplacé les serveurs WMS vers un nouveau sous‑réseau. La fenêtre de changement se termina, tout le monde rentra chez soi,
et l’ingénieur d’astreinte espérait la paix. Les scripts trimestriels, exécutés en post‑validation, échouèrent immédiatement :
les clients VPN entrepôt ne pouvaient plus joindre le WMS. La compta et l’IT allaient bien.

La cause racine était simple : les règles pare‑feu avaient été écrites avec les anciens sous‑réseaux explicites, et le nouveau sous‑réseau n’avait pas été ajouté.
Parce que la validation était automatisée et ciblée par groupe, l’échec fut détecté avant que la nuit ne commence à scanner des palettes.
La correction fut une petite mise à jour de politique et une relance des tests.

Rien d’héroïque. Pas de salle de crise. Pas de dirigeants. Juste une pratique ennuyeuse faisant son travail ennuyeux : empêcher le drame.

Listes de contrôle / plan pas à pas

Plan pas à pas pour implémenter des droits par groupe sur un seul VPN

1. Définissez les rôles comme des politiques d’accès, pas comme des unités orga.
   Créez 3–6 groupes d’accès VPN qui cartographient aux services atteignables.
   Évitez que « VPN-Employees » ne devienne « VPN‑Tout‑Le‑Monde‑Et‑Leur‑Prestataire ».
2. Créez des pools IP VPN distincts par groupe.
   Cela devient votre clé pare‑feu et votre poignée d’audit.
3. Choisissez la frontière d’application.
   Le meilleur : appliquer au pare‑feu entre VPN et segments internes. Suffisant : appliquer sur la passerelle VPN avec nftables/iptables. Pire : « on le fera dans les applis ».
4. Poussez des routes et DNS minimaux par groupe.
   Si la compta n’a jamais besoin du WMS, ne le publiez pas. Moins de routes = moins de surprises.
5. Mettez en place un forwarding par défaut‑deny.
   Puis autorisez des flux explicites (pool source → sous‑réseau/destinations → ports).
6. Journalisez les refus (avec limites raisonnables) et les autorisations admin.
   Vous voulez assez de preuves pour déboguer et auditer, pas assez pour fondre des disques.
7. Appliquez sur le stockage, pas seulement sur le réseau.
   Datasets/partages séparés ; ACL AD ; testez avec de vrais tokens utilisateurs.
8. Ajoutez un jump host pour l’accès admin IT.
   Gardez les interfaces de management hors de portée directe depuis le Wi‑Fi d’hôtel.
9. Définissez la durée de session et le comportement de réauth.
   Si l’appartenance au groupe change, les sessions doivent se rafraîchir dans une fenêtre temporelle prévisible.
10. Écrivez des tests de validation par groupe et exécutez‑les après les changements.
    Les tests de connectivité sont peu coûteux. Les pannes ne le sont pas.
11. Documentez le « pourquoi » à côté du « quoi ».
    Les commentaires de règles doivent indiquer quelle capacité métier est activée. Sinon les règles se multiplient comme des lapins.
12. Réalisez une revue d’accès trimestrielle incluant une vérification technique.
    « Revoir la liste de groupes » n’est pas une vérification. La vérification, ce sont des paquets, des journaux et des contrôles d’ACL.

Checklist opérationnelle pour les fenêtres de changement

• Avant le changement : snapshot/exportez les configs VPN et pare‑feu ; confirmez que le rollback fonctionne.
• Pendant le changement : mettez à jour routes, objets pare‑feu et DNS ensemble pour les applis impactées.
• Après le changement : lancez des tests de reachabilité par groupe ; confirmez que les refus restent des refus.
• Après le changement : vérifiez les journaux pour des drops/permits inattendus depuis les pools VPN.

Checklist sécurité qui n’entrave pas les opérations

• MFA pour le VPN basé utilisateur (surtout compta et IT).
• Pas de comptes admin IT partagés ; comptes nominatifs séparés pour les accès privilégiés.
• Accès « break‑glass » documenté et testé (oui, testé).
• Rotation des clés/certs ; expirez les anciens profils ; révoquez rapidement lors d’un offboarding.
• Restreindre le mouvement latéral : les clients VPN ne doivent pas pouvoir se parler entre eux sauf nécessité explicite.

FAQ

1) Puis‑je faire cela avec un seul serveur VPN, ou ai‑je besoin de serveurs séparés par département ?

Un seul serveur suffit s’il peut attribuer des IPs/routes différentes selon l’identité et que vous appliquez la politique sur un pare‑feu.
Des serveurs séparés sont parfois utilisés pour le confort politique ; techniquement, ils sont souvent une complexité inutile.

2) Est‑il préférable d’appliquer la politique sur la passerelle VPN ou sur un pare‑feu interne ?

Privilégiez la frontière du pare‑feu interne car elle centralise l’application et la journalisation pour tous les chemins d’entrée, pas seulement le VPN.
L’application sur la passerelle est acceptable pour les petits déploiements, mais elle tend à devenir une jungle de règles.

3) Ai‑je besoin de sous‑réseaux séparés (pools VPN) par groupe ?

Vous n’en avez pas absolument besoin, mais vous regretterez de ne pas l’avoir fait.
Des pools séparés rendent les politiques lisibles, le débogage plus rapide et les audits soutenables.

4) Qu’en est‑il des contractuels qui ont besoin d’accès compta pour un mois ?

Mettez‑les dans un groupe d’accès à durée limitée avec un workflow d’expiration explicite.
Ne les ajoutez pas au groupe principal compta « temporairement ». Le provisoire construit le risque permanent.

5) Les scanners d’entrepôt doivent‑ils utiliser la même méthode VPN que les laptops ?

Pas nécessairement. Les scanners fonctionnent souvent mieux avec une identité basée appareil et des routes verrouillées.
Si les scanners sont partagés, les politiques basées utilisateur ne se mappent pas proprement sans gestion d’appareils.

6) Le split tunneling est‑il acceptable dans ce modèle ?

Parfois. Si les endpoints sont gérés et que vous minimisez le backhaul, le split tunnel peut être raisonnable.
Pour l’accès admin IT et les opérations financières, le tunnel complet est souvent plus sûr car vous contrôlez le DNS et l’inspection d’egress.

7) Pourquoi ne puis‑je pas me reposer uniquement sur les logins applicatifs (ERP/WMS) et éviter les restrictions réseau ?

Parce que le réseau est l’endroit où résident le scan, l’exploitation et le mouvement latéral.
Les applis protègent l’appli ; la politique réseau réduit la surface d’attaque atteignable et limite les « oups j’ai connecté au mauvais truc ».

8) Comment prouver aux auditeurs que l’entrepôt ne peut pas accéder aux données finance ?

Fournissez des preuves empilées : politique pare‑feu montrant des refus (et logs de tentatives depuis des comptes tests),
plus preuves d’ACL stockage montrant que les partages finance refusent les groupes entrepôt. Points bonus pour des scripts de test reproductibles.

9) Quelle est la façon la plus propre de gérer les besoins larges de l’IT sans leur donner « tout le réseau » ?

Utilisez des jump hosts et des workflows d’accès privilégié. L’IT atteint le jump host ; le jump host atteint les réseaux de gestion.
Vous le journalisez. Vous le contrôlez. Vous pouvez le révoquer sans réécrire chaque règle pare‑feu.

10) Comment éviter la dérive des politiques dans le temps ?

Traitez la politique VPN et pare‑feu comme du code : revues, changements en environnements progressifs, et tests automatiques par groupe.
La dérive arrive quand on traite la politique réseau comme un tableau blanc.

Conclusion : prochaines étapes exécutables

Les droits par groupe sur un seul VPN ne sont pas une fonctionnalité produit. C’est une discipline de conception.
L’approche gagnante est ennuyeuse : identité → mappage de groupe → pools IP distincts → politique pare‑feu explicite → application des ACL stockage → journaux exploitables.
Tout le reste, c’est du théâtre.

Prochaines étapes pour avancer cette semaine :

1. Créez (ou nettoyez) trois groupes d’accès : VPN-Accounting, VPN-Warehouse, VPN-IT. Rendez les règles d’appartenance explicites.
2. Attribuez trois pools d’adresses VPN et assurez‑vous que les clients tombent toujours dans le bon pool.
3. Implémentez un forwarding default‑deny et écrivez des règles allow par pool vers seuls sous‑réseaux/ports requis.
4. Déplacez les données finance dans leur propre partage/dataset et appliquez des ACLs via les groupes d’annuaire.
5. Construisez une petite suite de validation : un compte test par groupe, cinq vérifications de connectivité, et un test négatif (entrepôt → SMB finance doit échouer).
6. Opérationnalisez : journalisez les refus, révisez les changements, et faites du « droits changés → réauth session » un runbook documenté.

Faites cela, et « un seul VPN » cessera d’être un compromis de sécurité et redeviendra ce qu’il aurait dû être : un point d’entrée gérable avec accès contrôlé.