Contrôle d’accès inter-bureaux : appliquer la règle « seuls les serveurs, pas tout le LAN »

décembre 20, 2025 • février 3, 2026 • Lecture : 29 min • Views: 7

Cet article vous a aidé ?

Vous voulez connecter deux bureaux — mais vous ne voulez pas que chaque imprimante, portable BYOD ou caméra IoT « temporaire » du bureau A ait un accès direct aux postes du bureau B. Vous voulez la règle sobre et sensée : le trafic inter-bureaux est réservé aux serveurs et à un petit ensemble de services gérés, pas à tout le LAN.

La plupart des équipes disent vouloir cela. Puis un VPN « rapide » est déployé, des routes sont fuitées, et soudain vous avez un réseau plat distribué avec deux kitchenettes. Le travail ici est de garder la connexion tout en réduisant le rayon d’explosion.

Le modèle : les bureaux sont non fiables, les services sont autorisés

« Seuls les serveurs, pas tout le LAN » ressemble à une règle de pare‑feu. C’est en réalité une posture réseau :

Les segments utilisateurs des bureaux sont bruyants, imprévisibles et remplis d’appareils que vous ne patcherez pas assez vite.
Les segments serveurs (ou « réseaux de service ») sont gérés, surveillés, et sont l’endroit où vous pouvez faire appliquer l’identité et le principe du moindre privilège.
La connectivité inter-bureaux doit être traitée comme une frontière hostile, même si l’autre bureau est « chez nous ».

Concrètement, « seulement les serveurs » signifie :

Entre le bureau A et le bureau B, seuls un petit ensemble de sous‑réseaux de destination sont joignables (par ex. 10.20.10.0/24 pour les serveurs, pas 10.20.0.0/16 pour tout).
Même au sein des sous‑réseaux autorisés, seuls les ports nécessaires sont ouverts (par ex. 443 vers des reverse proxies, 22 uniquement depuis des bastions, 445 uniquement depuis une passerelle de services de fichiers — si nécessaire).
Routage et politique doivent s’aligner : vous n’annoncez pas une route que vous comptez bloquer, et vous ne bloquez pas quelque chose que vous annoncez accidentellement avec un préfixe plus spécifique.
La journalisation est non‑négociable à la frontière. Si vous ne pouvez pas répondre à « qui a initié quoi vers où », vous ne contrôlez pas l’accès — vous devinez.

Prise de position : si votre « VPN inter-bureaux » n’est qu’un tunnel avec 0.0.0.0/0 des deux côtés et que vous comptez sur les pare‑feu des hôtes pour vous sauver, vous construisez une chaîne d’incidents.

Définissez « serveur » de manière précise

Les équipes butent parce que « serveur » devient une impression. Rendez‑le concret :

Sous‑réseaux serveurs sont des plages IP dédiées à des charges gérées (clusters de VM, nœuds conteneurs, NAS, AD/LDAP, reverse proxies).
Sous‑réseaux clients sont les terminaux utilisateurs (filaire, Wi‑Fi, invités, laboratoires, salles de réunion).
Sous‑réseaux d’infrastructure sont les équipements réseau, la supervision, les plans de gestion, les jump hosts et les concentrateurs VPN.

Puis codifiez : la connectivité inter‑bureaux n’est autorisée qu’aux sous‑réseaux serveurs + infra, avec une liste d’autorisation par port, et de préférence avec une couche d’identité (mTLS, proxies basés SSO, ou posture des appareils).

Faits et historique qui expliquent pourquoi ça tourne mal

Un peu de contexte aide. Pas parce que c’est mignon, mais parce que ces modes de défaillance se répètent pour les mêmes raisons.

Les réseaux d’entreprise anciens sont devenus « plats » parce que c’était moins cher. Les VLANs et le routage inter‑VLAN ont souvent été ajoutés plus tard, pas conçus dès le départ.
Les VPN site‑à‑site ont explosé au début des années 2000 quand les liens Internet sont devenus suffisamment stables pour remplacer les lignes louées ; beaucoup de designs ont repris les hypothèses « WAN de confiance » de l’époque MPLS.
La culture MPLS a appris à faire confiance au cloud opérateur. Lors du passage aux VPN Internet, les équipes ont souvent gardé le routage « any‑to‑any », simplement chiffré.
CIDR (1993) a permis l’agrégation mais a aussi facilité la sur‑synthèse : annoncer un /16 parce que c’est propre, pas parce que c’est sûr.
Le NAT est devenu une béquille de sécurité dans beaucoup de bureaux. Il masque les adresses, mais n’applique pas le moindre privilège ; il complique juste le dépannage.
SMB et la découverte Windows supposaient historiquement l’adjacence LAN. Quand les bureaux sont reliés, le trafic de découverte fuit et devient des tickets « pourquoi ma connexion est lente ? ».
Les imprimantes ont été traitées comme inoffensives. Puis on apprend que beaucoup tournent sur des stacks anciens et peuvent être des points de pivot. Les imprimantes : le cadeau qui n’arrête pas d’imprimer — et parfois d’exfiltrer.
Les pare‑feu sont devenus plus rapides, donc les gens ont été plus paresseux. Lorsqu’une appliance peut pousser des dizaines de Gbps, « autoriser tout » semble sans risque. Ce ne l’est pas ; à l’échelle, les erreurs font plus de bruit.

Une citation à garder pour chaque revue de conception (idée paraphrasée) : « L’espoir n’est pas une stratégie. » — attribuée à Ed Catmull dans les cercles opérationnels ; la tournure varie, donc prenez l’idée, pas la phrase sacrée.

Architecture de référence : routes, politiques et points d’étranglement

Le schéma simple et efficace est aussi le plus défendable : un point d’étranglement par site, routage explicite, et politiques par défaut‑refuser. Le but est d’éviter une « application distribuée » où chaque pare‑feu d’hôte serait supposé parfait pour toujours.

Choisissez vos points d’étranglement

Pour chaque bureau, vous voulez un équipement (ou une paire HA) qui :

est le point de terminaison du tunnel site‑à‑site (ou de l’overlay SD‑WAN),
est la passerelle L3 pour les VLANs serveurs et clients (ou au moins le routeur inter‑VLAN),
est le point d’application des politiques inter‑bureaux,
est le point de journalisation.

Choix courants : appliance pare‑feu, routeur avec ACLs, passerelle Linux basée sur nftables, ou un edge SD‑WAN. La marque compte moins que la discipline : défaut‑refuser, autorisations étroites et annonces de routes mesurées.

Stratégie de routage : n’annoncez que ce que vous comptez permettre

C’est la partie que les gens sautent parce que ça paraît « réseau ». C’est aussi là où la politique devient réelle.

Options :

Routes statiques : bien pour les petits environnements, modes de panne évidents, facile à auditer. Mauvaises si vous scalez vers de nombreux sous‑réseaux et sites.
Routage dynamique (BGP/OSPF sur le tunnel) : évolutif et bascule rapide, mais il propagera vos erreurs à la vitesse du protocole.
Routage par politique SD‑WAN : gestion centralisée d’intention pratique, mais il faut comprendre l’underlay réel et ce qui se passe quand les politiques entrent en conflit.

Règle : n’annoncez pas les sous‑réseaux clients à travers la frontière inter‑bureaux. Si les clients du bureau A ont besoin d’un service au bureau B, ils doivent atteindre un point de service au bureau B (reverse proxy, gateway, jump host, application publiée), pas le VLAN client.

Stratégie de politique : défaut‑refuser avec autorisations explicites

À la frontière inter‑bureaux, implémentez une matrice de politiques qui contient :

Zones source (Bureau A client, Bureau A serveur, Bureau A infra)
Zones destination (Bureau B serveur, Bureau B infra)
Groupes de services (HTTPS, SSH via bastion, supervision, services d’annuaire, réplication de sauvegarde)
Journalisation pour les refus et pour un sous‑ensemble d’autorisations (ou au moins échantillonnage), afin de prouver que la réalité correspond à l’intention.

L’inspection stateful est votre alliée. Le routage asymétrique ne l’est pas. Nous diagnostiquerons cela plus tard, car ça vous arrivera.

Identité par-dessus : « sous‑réseau serveur » ne suffit pas

Les listes d’autorisations par sous‑réseau réduisent la surface d’attaque. Elles n’empêchent pas un serveur compromis de devenir une tête de pont.

Pour les chemins à haute valeur ajoutée, ajoutez :

mTLS entre services
SSH via des bastions (pas de SSH direct depuis les clients vers les réseaux de serveurs distants)
Proxies applicatifs (reverse proxies HTTP, gateways RDP, passerelles d’accès fichiers)
Posture des appareils (vérifications des appareils gérés) lorsque faisable

Oui, c’est du travail supplémentaire. Non, vous ne le regretterez pas à 02:00 du matin.

Options de contrôle et quand utiliser chaque outil

1) Filtrage de routes (meilleure première ligne)

Si le bureau distant n’apprend jamais la route vers votre VLAN client, la plupart des problèmes disparaissent. Le filtrage de routes est propre, évolutif, et ne dépend pas des performances d’inspection de paquets.

Utilisez‑le quand vous contrôlez le routage (statique ou BGP/OSPF) et que vous voulez une frontière de haute confiance.

2) Politique pare‑feu stateful (le vrai livre des règles)

Même avec le filtrage de routes, la politique pare‑feu est requise parce que :

certaines routes doivent exister (vers les sous‑réseaux serveurs), et
vous avez toujours besoin d’un contrôle par port et de la journalisation.

3) Microsegmentation / pare‑feu hôte (utile, pas suffisant seul)

Les pare‑feu hôtes (Windows Firewall, ufw, firewalld) et les agents de microsegmentation peuvent drastiquement réduire les mouvements latéraux. Mais comme seul contrôle ? C’est parier sur l’hygiène des endpoints. Ce pari perd un jour.

4) Publication applicative (meilleure expérience utilisateur dans beaucoup de cas)

Au lieu de laisser le bureau A atteindre largement les serveurs du bureau B, publiez des applications spécifiques :

Applications HTTPS derrière un reverse proxy avec SSO
RDP via une gateway avec MFA
SMB via une passerelle de fichiers ou un mécanisme de synchronisation

Quand les gens disent « nous avons besoin d’accès réseau », demandez ce dont ils ont réellement besoin. C’est souvent « une application web et un partage de fichiers », pas « découvrir tous les appareils dans un /16 ».

Blague 1 : Un réseau plat, c’est comme un open‑space : parfait pour collaborer, terrible pour empêcher quelqu’un d’entendre vos secrets.

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

Ce sont des vérifications pratiques que vous pouvez exécuter depuis des gateways Linux, des jump hosts serveurs, ou des postes d’administration. Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie, et la décision à prendre.

Task 1: Prove what routes you actually have (and whether client subnets leaked)

cr0x@server:~$ ip route show
default via 10.10.0.1 dev eth0 proto dhcp src 10.10.0.20 metric 100
10.10.0.0/24 dev eth0 proto kernel scope link src 10.10.0.20
10.20.10.0/24 via 10.10.0.1 dev eth0
10.20.30.0/24 via 10.10.0.1 dev eth0

Signification : Cet hôte peut router vers deux sous‑réseaux distants : 10.20.10.0/24 et 10.20.30.0/24. Si 10.20.30.0/24 est un VLAN client, vous avez déjà violé « seulement les serveurs ».

Décision : Corrigez d’abord l’annonce de routes ou les routes statiques. Ne « colmatez » pas les routes fuitées avec des règles hôtes.

Task 2: Check what your VPN interface thinks it’s doing

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             10.10.0.20/24 fe80::a00:27ff:fe4e:66a1/64
tun0             UP             172.31.255.2/30

Signification : L’interface tunnel est up avec un /30. C’est bien. Ça ne vous dit pas ce qui est routé dessus, seulement que l’interface existe.

Décision : Corrélez avec la table de routage et la politique pare‑feu ; ne supposez pas que « tun0 up » signifie « politique correcte ».

Task 3: Validate the path to a remote server subnet (and catch surprise detours)

cr0x@server:~$ tracepath -n 10.20.10.50
 1?: [LOCALHOST]                                         pmtu 1500
 1:  10.10.0.1                                            0.410ms
 2:  172.31.255.1                                         1.283ms
 3:  10.20.10.50                                          2.104ms reached
     Resume: pmtu 1500 hops 3 back 3

Signification : Le trafic va à la gateway locale, puis à travers le pair du tunnel, puis à la destination. Chemin propre, MTU 1500.

Décision : Si les sauts incluent des routeurs inattendus (comme un edge Internet), vous avez probablement du routage basé sur politique ou des fuites de routes.

Task 4: Check PMTU issues (classic “it pings but the app hangs”)

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.10.50
PING 10.20.10.50 (10.20.10.50) 1472(1500) bytes of data.
From 10.10.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.10.0.1 icmp_seq=2 Frag needed and DF set (mtu = 1400)
From 10.10.0.1 icmp_seq=3 Frag needed and DF set (mtu = 1400)

--- 10.20.10.50 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Signification : Le MTU effectif est 1400 sur le chemin. Les gros paquets avec DF posé ne passent pas. Certaines applications vont se bloquer ou retransmettre indéfiniment.

Décision : Limitez MSS sur le VPN/pare‑feu, ou réglez le MTU du tunnel de façon appropriée. Puis retestez avec des tailles plus petites/plus grandes jusqu’à stabilité.

Task 5: Confirm what the firewall is dropping (nftables example)

cr0x@gateway:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iifname "lan_clients" oifname "vpn0" ip daddr 10.20.10.0/24 tcp dport { 443 } accept
    iifname "lan_clients" oifname "vpn0" counter log prefix "DROP interoffice " drop
  }
}

Signification : Politique par défaut drop dans la chaîne forward. Autorise uniquement le VLAN client vers le sous‑réseau serveur distant sur 443. Tout le reste est journalisé et bloqué.

Décision : C’est la bonne forme. Ensuite, assurez‑vous que vos règles sont symétriques (chemin retour) et que vos zones correspondent aux interfaces réelles.

Task 6: Watch drops live to see what users are trying (and what you forgot)

cr0x@gateway:~$ sudo journalctl -k -f | grep "DROP interoffice"
Aug 21 10:13:02 gw kernel: DROP interoffice IN=lan_clients OUT=vpn0 SRC=10.10.50.23 DST=10.20.30.44 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=5421 DF PROTO=TCP SPT=51844 DPT=445 WINDOW=64240 SYN
Aug 21 10:13:04 gw kernel: DROP interoffice IN=lan_clients OUT=vpn0 SRC=10.10.50.23 DST=10.20.10.60 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=5512 DF PROTO=TCP SPT=51845 DPT=3389 WINDOW=64240 SYN

Signification : Quelqu’un tente du SMB (445) vers un sous‑réseau client distant (10.20.30.44), et du RDP (3389) vers un serveur (10.20.10.60). Votre politique n’avait autorisé que 443.

Décision : N’ouvrez pas à la hâte 445/3389. Demandez : SMB doit‑il traverser les bureaux ? Le RDP doit‑il passer par une gateway ? La réponse est généralement « publiez correctement ».

Task 7: Verify BGP advertisements aren’t leaking client ranges

cr0x@router:~$ vtysh -c "show ip bgp neighbors 172.31.255.1 advertised-routes" | sed -n '1,40p'
BGP table version is 44, local router ID is 10.10.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.20.10.0/24    0.0.0.0                  0         32768 i
*> 10.20.99.0/24    0.0.0.0                  0         32768 i

Signification : Vous annoncez deux préfixes. Si 10.20.99.0/24 est un VLAN client/Wi‑Fi, vous l’exportez sur le lien inter‑bureaux.

Décision : Ajoutez des prefix‑lists/route‑maps pour n’exporter que les préfixes serveurs et infrastructure. Puis confirmez sur le côté distant les routes reçues.

Task 8: Check received routes on the other side (confirm the fix worked)

cr0x@router-b:~$ vtysh -c "show ip bgp neighbors 172.31.255.2 received-routes" | sed -n '1,40p'
BGP table version is 107, local router ID is 10.20.0.1

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.20.10.0/24    172.31.255.2            0             0 i

Signification : Seul le sous‑réseau serveur est reçu. Bien. Moins de possibilités de surprise signifie moins de risques.

Décision : Gardez‑le ainsi. Si quelqu’un demande plus tard « accès temporaire » à un VLAN client, traitez‑le comme une demande de changement avec une date d’expiration.

Task 9: Confirm IP forwarding and rp_filter settings (asymmetric routing trap)

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

Signification : Le forwarding IP est activé. Le reverse path filtering est strict (1). Un rp_filter strict peut bloquer du trafic légitime lorsque les chemins de retour diffèrent (commun avec des liens doubles, SD‑WAN, ou routage par politique).

Décision : Si vous observez du trafic unidirectionnel avec des états valides, envisagez de régler rp_filter à 2 (loos) sur les interfaces VPN, mais seulement après avoir compris la symétrie du routage.

Task 10: Capture traffic at the boundary to distinguish “no route” vs “firewall drop”

cr0x@gateway:~$ sudo tcpdump -ni vpn0 host 10.10.50.23 and host 10.20.10.50 and tcp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vpn0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:15:22.011221 IP 10.10.50.23.51910 > 10.20.10.50.443: Flags [S], seq 405483990, win 64240, options [mss 1360,sackOK,TS val 120119 ecr 0,nop,wscale 7], length 0
10:15:22.032909 IP 10.20.10.50.443 > 10.10.50.23.51910: Flags [S.], seq 29199210, ack 405483991, win 65160, options [mss 1360,sackOK,TS val 99122 ecr 120119,nop,wscale 7], length 0

Signification : SYN et SYN‑ACK sont visibles sur vpn0. La poignée de main se produit. Si le client échoue encore, le problème est probablement au‑delà de la frontière inter‑bureaux (pare‑feu hôte, TLS, proxy, application).

Décision : Arrêtez de modifier VPN/pare‑feu et montez dans la pile applicative.

Task 11: Test port reachability without lying to yourself

cr0x@client-jumphost:~$ nc -vz -w 3 10.20.10.50 443
Connection to 10.20.10.50 443 port [tcp/https] succeeded!

Signification : La connexion TCP fonctionne. C’est suffisant pour L3/L4. Cela ne confirme pas que l’application est correcte.

Décision : Si la connexion échoue, vérifiez les drops pare‑feu et les routes. Si elle réussit mais que l’application échoue, vérifiez les certificats TLS, SNI, proxies et ACL côté serveur.

Task 12: Confirm that a remote client subnet is truly unreachable (the goal)

cr0x@client-jumphost:~$ ping -c 2 10.20.30.44
PING 10.20.30.44 (10.20.30.44) 56(84) bytes of data.

--- 10.20.30.44 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1021ms

Signification : Pas de réponse ICMP. Cela ne prouve pas à lui seul que c’est bloqué (ICMP peut être filtré), mais c’est un bon signal lorsqu’il est corrélé avec la table de routage et les logs du pare‑feu.

Décision : Validez avec ip route get 10.20.30.44 et les compteurs/journaux du pare‑feu. Votre objectif : pas de route, ou un drop explicite avec logs.

Task 13: Show which rule is matching (iptables counters example)

cr0x@gateway:~$ sudo iptables -L FORWARD -v -n --line-numbers | sed -n '1,25p'
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in          out         source          destination
1     918K  712M ACCEPT     all  --  *           *           0.0.0.0/0       0.0.0.0/0       ctstate RELATED,ESTABLISHED
2     231K   18M ACCEPT     tcp  --  lan_clients vpn0        10.10.50.0/24    10.20.10.0/24    tcp dpt:443
3     1245  104K DROP       all  --  lan_clients vpn0        0.0.0.0/0       0.0.0.0/0

Signification : La règle 2 est activement utilisée ; la règle 3 bloque le reste. Les compteurs rendent la politique tangible. Si la règle 3 augmente de façon inattendue, des utilisateurs/applications tentent des chemins interdits.

Décision : Investiguer ce qui est bloqué avant d’ajouter de nouvelles autorisations. Parfois la bonne correction est « arrêtez de faire ça », pas « ouvrez le pare‑feu ».

Task 14: Prove DNS isn’t causing “it’s down” illusions across offices

cr0x@client-jumphost:~$ dig +short app.officeb.internal
10.20.10.50

Signification : Le nom résout vers une IP du sous‑réseau serveur. Bien. S’il résout vers un sous‑réseau client ou une IP publique de façon inattendue, votre plan de contrôle d’accès semblera « aléatoire » aux utilisateurs.

Décision : Assurez‑vous que les réponses DNS internes diffèrent par site seulement quand c’est intentionnel. Ne laissez pas le DNS split‑horizon devenir un split‑brain.

Checklist de diagnostic rapide

C’est l’ordre qui trouve le goulot rapidement, sans modifier frénétiquement et empirer la situation.

Première étape : vérité du routage (joignabilité au L3)

Sur l’hôte source : ip route get <dest-ip> pour voir l’interface de sortie et le prochain saut.
Sur la gateway : confirmez que la route existe et pointe dans le tunnel/overlay SD‑WAN.
Sur la gateway distante : confirmez que la route de retour existe vers le sous‑réseau source (ou que la politique NAT est délibérée et cohérente).

S’il n’y a pas de route, arrêtez. Corrigez l’annonce de routes ou les routes statiques avant de toucher aux règles pare‑feu.

Deuxième étape : politique pare‑feu et compteurs (est‑ce bloqué ou autorisé ?)

Vérifiez la politique par défaut : drop ou accept.
Vérifiez l’autorisation explicite pour le tuple exact : src subnet, dst subnet, protocole, port.
Vérifiez les compteurs/journaux pendant la reproduction du problème.

Si les compteurs montrent des drops, décidez : s’agit‑il d’une requête légitime (publier/la passerelle), ou d’un mouvement latéral en attente (continuer à bloquer) ?

Troisième étape : état et asymétrie (le piège « ça devrait marcher »)

Recherchez des chemins de retour asymétriques (dual WAN, routage par politique, ECMP, événements de bascule SD‑WAN).
Vérifiez rp_filter et le comportement de la table d’état.
Utilisez tcpdump sur les deux interfaces (LAN et VPN) pour confirmer que les paquets traversent comme prévu.

Quatrième étape : MTU et fragmentation (le tueur silencieux)

Utilisez ping -M do avec des tailles pour trouver le MTU fonctionnel.
Cherchez « Frag needed and DF set ».
Limitez MSS sur le tunnel.

Cinquième étape : couche applicative et identité

Testez la connexion TCP (nc), puis TLS (openssl s_client si besoin), puis l’application réelle.
Vérifiez les pare‑feu et ACL côté serveur.
Validez les réponses DNS depuis le site affecté.

Erreurs courantes : symptôme → cause → correction

Ceux‑ci reviennent souvent parce qu’ils sont séduisants.

1) « On n’a autorisé que les sous‑réseaux serveurs, mais les utilisateurs atteignent quand même des postes distants »

Symptôme : Des utilisateurs du bureau A font du RDP sur des machines aléatoires du bureau B.

Cause racine : Le « sous‑réseau serveur » contient des pools VDI, des jump boxes avec portée large, ou des postes mal classifiés. Ou vous avez autorisé 3389 largement au VLAN serveur.

Correction : Séparez les admin/jump/VDI en sous‑réseaux distincts et appliquez des règles plus strictes. Utilisez une gateway RDP avec MFA ; bloquez le 3389 direct inter‑bureaux.

2) « Les pings passent, HTTPS time‑out »

Symptôme : L’ICMP passe, la poignée de main TCP peut‑être aussi, mais les grosses réponses stagnent.

Cause racine : Incompatibilité MTU/MSS dans le tunnel ou overlay ; PMTUD bloqué.

Correction : Limitez MSS sur le bord VPN, autorisez les ICMP fragmentation‑needed, réglez le MTU du tunnel correctement, puis vérifiez avec des pings DF.

3) « On a tout bloqué, maintenant rien ne fonctionne — même ce qui était autorisé »

Symptôme : Même les règles d’autorisation explicites semblent ignorées.

Cause racine : Mauvaise cartographie zone/interface, politique appliquée dans le mauvais sens, ou contournement de politique à cause de l’offload matériel/fast‑path.

Correction : Validez les noms d’interfaces, l’appartenance aux zones, et l’ordre des règles. Désactivez temporairement le fast‑path pour le dépannage. Confirmez avec compteurs et tcpdump.

4) « Après une bascule, certains flux meurent et ne se rétablissent jamais »

Symptôme : Un failover SD‑WAN se produit ; certains utilisateurs se reconnectent, d’autres restent bloqués.

Cause racine : Les appareils stateful perdent leurs tables de session lors du changement de chemin ; routage asymétrique pour le retour ; rp_filter strict qui bloque les paquets de retour.

Correction : Assurez la symétrie du routage ou la synchronisation de session en HA. Utilisez des politiques NAT cohérentes. Envisagez rp_filter en mode loose sur les interfaces tunnel.

5) « Nous n’avions pas annoncé les sous‑réseaux clients, mais le bureau distant y accède quand même »

Symptôme : Vous jurez que les routes sont filtrées, pourtant la connectivité existe.

Cause racine : Quelqu’un a ajouté une route statique supernet, ou une route par défaut traverse le tunnel, ou un NAT provoque un hairpin involontaire.

Correction : Auditez les routes statiques sur les gateways, vérifiez les 0/0 ou grandes synthèses dans les sélecteurs VPN/crypto ACLs, et confirmez avec ip route et les tables BGP.

6) « L’accès aux partages est intermittent et lent entre bureaux »

Symptôme : SMB fonctionne, mais les utilisateurs se plaignent constamment.

Cause racine : SMB bavard sur des liens à plus grande latence, problèmes d’opportunistic locking, et trafic de découverte/nommage bloqué de façons étranges.

Correction : N’étendez pas SMB entre bureaux en premier recours. Utilisez DFS avec un design soigné, synchronisation de fichiers, ou publication via une gateway proche des utilisateurs.

7) « L’équipe sécurité demande ‘zéro trust’ mais on a besoin de monitoring »

Symptôme : La supervision ou les sauvegardes cassent après la segmentation.

Cause racine : La supervision/sauvegarde dépendait implicitement d’une large joignabilité (ICMP, SNMP, agents, RPC).

Correction : Faites de la supervision un service de première classe : sous‑réseau dédié, ports explicites, et idéalement agents pull avec mTLS.

Blague 2 : Un VPN sans filtrage n’est qu’un long câble Ethernet avec un tampon de passeport.

Trois mini‑récits d’entreprise tirés du terrain

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

Deux bureaux. Un site « corporate », un site « satellite ». Le satellite avait besoin d’accéder à une poignée d’applications web internes et à un bastion SSH. L’équipe réseau a déployé un tunnel site‑à‑site et a demandé que « les sous‑réseaux » soient routés.

Le propriétaire applicatif a répondu : « On utilise 10.40.0.0/16. » C’était vrai de la même façon que « l’océan est humide » est vrai : techniquement exact, opérationnellement inutile. À l’intérieur de ce /16 se trouvaient VLANs serveurs, VLANs utilisateurs, imprimantes, et un réseau de labo où des ingénieurs testaients des choses qu’ils n’auraient probablement pas dû.

La mauvaise hypothèse était simple : « Si c’est interne, c’est de confiance. » En une semaine, un laptop compromis au satellite (phishing, rien d’exotique) a scanné à travers le tunnel, trouvé un ancien partage SMB sur un VLAN poste de travail au siège, et l’a utilisé comme pivot. L’attaquant n’avait pas besoin d’un zero‑day. Il lui fallait joignabilité et du temps.

Les forensics furent inconfortables. Pas parce que l’exploit était malin — il ne l’était pas — mais parce que les logs étaient maigres. L’appliance VPN avait « allow any » avec une journalisation minimale pour « éviter le bruit ». L’équipe endpoint affirmait que le laptop était patché. L’équipe réseau affirmait que le tunnel était « privé ». Tout le monde avait raison d’une manière qui mène à une compromission.

La correction n’était pas héroïque. Ils ont arrêté d’annoncer le /16, découpé le réseau en préfixes serveurs publiés, et forcé l’accès admin via un bastion avec MFA. Le rapport d’incident a répété « segmentation » une quarantaine de fois. La leçon réelle tient en moins de mots : arrêtez de router ce que vous ne voulez pas sécuriser.

Mini‑récit 2 : L’optimisation qui a mal tourné

Une entreprise de taille moyenne a déployé du SD‑WAN pour connecter plusieurs bureaux. La performance a immédiatement amélioré ; la gigue a chuté et les appels vidéo n’avaient plus l’air d’interviews sous l’eau. L’équipe réseau a ensuite « optimisé » la politique de sécurité : au lieu de dizaines de règles granulaires, ils les ont résumées en quelques règles larges. Moins de règles, moins d’erreurs. Raisonnable, non ?

Le problème était la synthèse. Ils ont remplacé plusieurs préfixes serveurs par un agrégat plus large. Cela a rendu le routage plus propre et la politique pare‑feu plus courte. Cela a aussi inclus subrepticement un VLAN « temporaire » pour des contractuels, dont les appareils étaient gérés… dans le sens où quelqu’un les avait gérés une fois.

Au début rien ne s’est passé. C’est pourquoi cette classe d’erreur est dangereuse : elle attend. Puis une machine de contractuel a commencé à générer du trafic suspect vers un service Git interne dans un autre bureau. L’accès n’a pas été bloqué parce que ça matchait la nouvelle règle agrégée. L’alerte n’a pas déclenché parce que le trafic ressemblait à du HTTPS normal.

Le postmortem n’a pas épargné l’optimisation. Ils n’ont pas perdu de données, mais ils ont perdu du temps. Beaucoup. L’équipe a dû annuler l’agrégat, identifier ce que le VLAN contractuel devait réellement accéder (presque rien), et introduire des route‑maps pour empêcher l’inclusion accidentelle dans de futures synthèses.

Conclusion : l’agrégation est une optimisation de performance ; la segmentation est une décision de risque. Ne laissez pas une commodité de routage réécrire votre modèle de sécurité.

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

Une organisation financière avec deux bureaux principaux avait une politique inter‑bureaux stricte : seuls les sous‑réseaux serveurs, seuls des ports spécifiques, et toutes les règles étaient sous contrôle de changement avec un propriétaire et une date d’expiration. Ce n’était pas excitant. Les gens se plaignaient du processus. Naturellement.

Un après‑midi, un ticket helpdesk arrive : « Un utilisateur du bureau A ne peut pas accéder à quelque chose au bureau B. » La demande semblait légitime et urgente. La pression habituelle commence : « Ouvrez rapidement temporairement. »

Le SRE de garde a fait la chose ennuyeuse. Il a vérifié les logs du pare‑feu et a vu des tentatives répétées vers TCP/445 et TCP/135 entre bureaux depuis un VLAN utilisateur — schéma classique de mouvement latéral, pas « accéder à l’app ». Il a aussi vérifié le DNS et constaté que l’utilisateur essayait d’atteindre un nom qui résolvait vers un sous‑réseau poste de travail au bureau B, pas vers le point de service publié.

Au lieu d’ouvrir le pare‑feu, il a corrigé le problème : mis à jour le DNS pour que le nom pointe vers un reverse proxy dans le VLAN serveur, et ajouté une autorisation étroite à TCP/443 uniquement pour ce proxy. Pendant ce temps, l’équipe sécurité a investigué le poste utilisateur. Il s’avère qu’il était infecté par quelque chose qui testait sa chance.

Rien de dramatique ne s’est produit parce que la politique était conçue pour rendre les choses dramatiques ennuyeuses. C’est l’objectif : rendre le chemin sûr le plus simple, et le chemin dangereux bruyant et bloqué.

Listes de contrôle / plan pas à pas

Plan pas à pas : implémenter « seulement les serveurs » sans casser le business

Inventoriez les sous‑réseaux par fonction : client, serveur, infra, invité, labo. Si vous ne pouvez pas étiqueter un sous‑réseau, il n’est pas prêt à être routé n’importe où.
Définissez les préfixes de destination autorisés par bureau : habituellement serveurs + infra seulement. Gardez‑les courts.
Définissez les ports de service par cas d’usage :
- Apps web : 443 vers reverse proxies
- Admin : 22 uniquement depuis des bastions ; évitez le SSH direct bureau→serveur
- Annuaire : seulement ce qui est requis, depuis des sources spécifiques
- Supervision : depuis le sous‑réseau de supervision seulement
Corrigez le routage en premier : filtrage de routes ou routes statiques pour les seuls préfixes autorisés. N’exportez pas les VLANs clients.
Appliquez les politiques pare‑feu : défaut‑refuser, autorisations explicites, avec journalisation. Assurez‑vous que les deux sens sont pris en compte (les politiques stateful aident, mais ne comptez pas sur la magie).
Décidez de la politique NAT : idéalement aucune pour interne→interne, mais si vous devez faire du NAT, faites‑le de façon cohérente et documentez pourquoi. Le NAT peut cacher des péchés de routage ; il ne les excuse pas.
Publiez des apps plutôt que des réseaux quand possible : reverse proxies, gateways, SSO, MFA. Les utilisateurs veulent des applications, pas des sous‑réseaux.
Mettez en place un workflow de changement : chaque nouvelle autorisation inter‑bureaux a un propriétaire et une date d’expiration. Les règles temporaires permanentes sont un mensonge.
Testez des deux côtés : vérifications de routes, de ports et d’applications. Validez le MTU tôt.
Baselinez logs et compteurs : vous devez pouvoir répondre « qu’est‑ce qui a été bloqué » et « qu’est‑ce qui a été autorisé » lors d’un incident.
Faites un exercice tabletop : simulez une fuite de route ou un préfixe mal synthétisé et vérifiez la détection (alertes sur nouveaux préfixes, pics de drops, flux inattendus).

Checklist opérationnelle : quoi surveiller en continu

Nouvelles routes apprises sur l’adjacence inter‑bureaux (surtout agrégats larges et VLANs clients).
Compteurs de règles pare‑feu pour « deny interoffice » (les pics signifient souvent scan ou mauvaise config).
Indicateurs MTU/fragmentation du tunnel et retransmissions TCP.
Événements de changement de chemin SD‑WAN et failover corrélés aux plaintes applicatives.
Anomalies DNS : noms internes résolvant vers des sous‑réseaux inattendus selon le site.
Signaux d’identité : échecs MFA, usage anormal des bastions, comportement anormal de comptes de service.

FAQ

1) Bloquer par routes est‑il mieux que bloquer par pare‑feu ?

Oui, quand c’est possible. Le filtrage de routes réduit la surface joignable avant même que les paquets n’atteignent la politique. Utilisez les deux : filtrage de routes pour la joignabilité, pare‑feu pour les ports et la journalisation.

2) Nous avons besoin que les utilisateurs du bureau A accèdent à une base de données au bureau B. Autorisons‑nous le sous‑réseau DB ?

Préférez la publication via une couche applicative ou un proxy au bureau B. Si vous devez autoriser l’accès DB, restreignez‑le à des sous‑réseaux (ou hôtes) sources spécifiques et à des ports précis, et journalisez. Les bases de données ne sont pas des services cross‑office à ouvrir à la légère.

3) Peut‑on se fier au pare‑feu Windows sur les serveurs au lieu des pare‑feu réseau ?

Utilisez Windows Firewall, oui. Mais ne vous y fiez pas comme unique frontière. L’application réseau vous donne une politique centralisée, des logs centralisés, et un point d’étranglement plus difficile à contourner.

4) Mais on fait confiance à nos bureaux parce que c’est la même boîte ?

La confiance n’est pas un primitif de conception réseau. Les bureaux contiennent des appareils non gérés, des contractuels, du matériel de salle de réunion, et des terminaux utilisateurs qui naviguent sur Internet toute la journée. Traitez le lien inter‑bureaux comme un transport non fiable transportant des services explicitement autorisés.

5) Devrait‑on faire du NAT entre bureaux pour « cacher » des réseaux ?

Seulement si vous avez une raison claire (espaces IP qui se chevauchent, intégration suite à une acquisition). Le NAT peut simplifier les collisions d’adressage, mais complique le dépannage, casse certains protocoles, et crée une fausse confiance. Si vous NATez, documentez‑le et standardisez‑le.

6) Comment gérer des plages RFC1918 qui se chevauchent après une acquisition ?

À court terme : NAT à la frontière, et gardez les services autorisés étroits. À moyen terme : renumérotez un des côtés ou introduisez un segment de traduction avec une propriété claire. À long terme : arrêtez de traiter l’espace IP comme un détail lors des intégrations.

7) L’équipe sécurité parle de « zero trust ». Qu’est‑ce que cela implique pour l’inter‑bureaux ?

Que la localisation réseau ne suffit pas. Gardez des listes d’autorisation par sous‑réseau, mais ajoutez l’identité : mTLS, proxies SSO, posture des appareils, et MFA pour les accès admin. « Seulement les serveurs » devient « seulement des services spécifiques sur des serveurs spécifiques avec identité vérifiée ».

8) Comment empêcher les règles « temporaires » de devenir permanentes ?

Rendez les dates d’expiration obligatoires, et automatisez les rappels (ou la désactivation automatique) à l’échéance. Si une règle est encore nécessaire, renouvelez‑la avec une justification. La friction est une fonctionnalité.

9) Quels ports ne devraient jamais être largement autorisés entre bureaux ?

De façon générale : SMB (445), NetBIOS (137–139), RPC endpoint mapper (135), et RDP direct (3389). Il y a des exceptions, mais elles doivent ressembler à des exceptions et être accompagnées de contrôles compensatoires.

10) Quelle est la preuve la plus rapide que nous avons atteint « seulement les serveurs » ?

Depuis un VLAN client du bureau A, vous devriez avoir (a) aucune route vers les VLANs clients du bureau B, et (b) des logs pare‑feu montrant des drops pour toute tentative d’accès. Depuis des sources approuvées, les ports approuvés vers les sous‑réseaux serveurs doivent réussir avec des compteurs propres.

Conclusion : prochaines étapes réalisables cette semaine

« Seuls les serveurs, pas tout le LAN » n’est pas un slogan. C’est une conception que vous faites respecter avec de la discipline de routage, une politique défaut‑refuser, et des logs qui disent la vérité quand quelqu’un insiste « ça marchait avant ».

Étapes pratiques :

Listez chaque sous‑réseau dans les deux bureaux et étiquetez‑le client/serveur/infra/invité/labo.
Cessez d’annoncer les VLANs clients sur le lien inter‑bureaux. Utilisez des prefix‑lists ou resserrez les routes statiques.
Implémentez une politique pare‑feu inter‑bureaux défaut‑refuser avec des autorisations explicites vers les sous‑réseaux serveurs et des ports restreints.
Publiez les applications via des gateways/proxies plutôt que d’ouvrir un large accès réseau (surtout pour RDP et SMB).
Ajoutez journalisation et compteurs, puis établissez une baseline de ce qui est « normal » avant que le prochain incident ne vous enseigne la leçon durement.

Si vous ne faites qu’une chose : filtrez les routes pour que les mauvais réseaux ne soient tout simplement pas joignables. Tous les autres contrôles deviennent plus simples quand la joignabilité est contrainte.