Deux bureaux en 192.168.0.0/24 : les connecter sans renumérotation

octobre 15, 2025 • février 3, 2026 • Lecture : 28 min • Views: 7

Cet article vous a aidé ?

Vous obtenez enfin l’autorisation de connecter le bureau A et le bureau B. Puis vous découvrez que les deux LAN sont en 192.168.0.0/24, comme par hasard. Tout le monde veut « juste un VPN », mais le routage ne fait pas de magie : si les deux côtés revendiquent les mêmes adresses, les paquets ne savent pas où se trouve « 192.168.0.50 ».

C’est la réalité du réseau de petite entreprise qui rencontre la connectivité « adulte ». La bonne nouvelle : vous pouvez les connecter sans renumérotation. La mauvaise nouvelle : il faut être précis sur ce que vous entendez par « sans renumérotation », car certaines approches sont du ruban adhésif et d’autres sont une vraie attache.

Ce qui casse réellement quand les sous-réseaux se chevauchent

Si les deux bureaux utilisent 192.168.0.0/24, vous n’avez pas « un problème de routage », vous avez un problème d’identité. Les adresses IP sont censées identifier des points de terminaison. Quand deux points de terminaison partagent la même identité, les choses deviennent étranges très vite.

Pourquoi un simple VPN site-à-site échoue

Les designs classiques de VPN site-à-site partent de cette hypothèse : « Le trafic destiné au sous-réseau X passe dans le tunnel. » Avec un chevauchement, les deux sites croient être le sous-réseau X. Donc :

Un hôte du bureau A envoie vers 192.168.0.50. Son OS décide « c’est sur mon LAN local », fait de l’ARP et n’envoie jamais le paquet vers le VPN.
Si vous le forcez dans le VPN (routage politique, règles de pare-feu), l’autre côté reçoit un paquet dont l’adresse source semble elle aussi locale, et les réponses sont mal routées.
Même si vous « parvenez à le faire fonctionner en quelque sorte », tous les services qui intègrent des IP dans des ACL, des logs ou des configurations deviendront ambigus et pénibles.

Blague n°1 : les sous-réseaux qui se chevauchent, c’est comme avoir deux collègues appelés « Alex » sur la même rotation d’astreinte. On peut s’arranger, mais vos alertes deviendront de l’art performance.

Les trois collisions que vous rencontrerez

Collision de décision de forwarding : les hôtes considèrent les destinations du même sous-réseau comme sur le lien local. Ils font de l’ARP, pas du routage.
Collision de chemin de retour : les réponses partent au mauvais endroit parce que source/destination semblent locales sur les deux côtés.
Collision d’état : les pare-feu/tables NAT ne distinguent pas de manière fiable des flux qui partagent la même sémantique 5-tuple entre sites si vous ne traduisez pas quelque chose.

La solution consiste toujours à rendre le trafic non ambigu. Vous y parvenez en traduisant les adresses, en isolant les tables de routage, ou en montant la connectivité dans la couche applicative (overlay/proxy).

Faits intéressants et contexte historique

Un peu de perspective aide, car ce bazar n’est pas nouveau — c’est le résultat prévisible des adresses privées et de décennies de « on expédie comme ça ». Voici quelques éléments concrets de contexte qui expliquent pourquoi les sous-réseaux qui se chevauchent sont si fréquents :

RFC 1918 (1996) a popularisé l’espace d’adresses privées (10/8, 172.16/12, 192.168/16), facilitant le choix des mêmes sous-réseaux indépendamment.
192.168.0.0/24 est devenu « le LAN par défaut » principalement parce que les premiers routeurs grand public l’avaient en configuration par défaut, et l’inertie est une force puissante.
NAT a d’abord été traité comme un bricolage pragmatique pour économiser des adresses IPv4 ; il est ensuite devenu un placebo de sécurité et une dépendance architecturale.
IPsec a été conçu pour la sécurité réseau-à-réseau, mais pas pour les collisions d’identité ; le NAT traversal (NAT-T) a résolu un problème différent (NAT sur le chemin), pas les LAN qui se chevauchent.
Les appliances VPN anciennes poussaient souvent des tunnels basés sur des politiques (domaines de chiffrement). Ce modèle s’effondre en cas de chevauchement sauf si vous ajoutez de la traduction.
Les VRF (virtual routing and forwarding) viennent de la technologie opérateur/ISP pour garder distinctes les routes clients sur une infrastructure partagée ; c’est aujourd’hui le moyen le plus propre de distinguer des réseaux qui se chevauchent.
Le DNS split-horizon existait bien avant le cloud, et c’est encore un outil pratique quand la connectivité IP est chaotique mais que les noms peuvent être homogénéisés.
IPv6 était censé mettre fin à tout ça. Au lieu de cela, beaucoup d’organisations gardent un dual-stack partiel, conservent des LAN IPv4 privés et continuent de se chevaucher.

Arbre de décision : que vous devriez faire (et ce que vous regretterez)

« Sans renumérotation » peut signifier plusieurs choses. Soyez explicite avant de toucher un pare-feu :

Exigence stricte : les points de terminaison conservent leurs IP actuelles et se parlent directement par IP.
Exigence souple : les points de terminaison conservent leurs IP, mais peuvent atteindre les services distants via de nouvelles IP, des noms DNS ou un proxy.
Exigence temporaire : garder les IP pour l’instant, connecter les sites, puis planifier une renumérotation plus tard.

Mon conseil tranché :

Si vous avez besoin d’une large portée L3 entre la plupart des hôtes des deux côtés : utilisez le NAT entre sites (aussi appelé traduction réseau, NAT-on-a-stick, netmap) ou les VRF si vous êtes en environnement routeur sérieux.
Si seulement quelques services doivent être accessibles (serveur de fichiers, passerelle RDP, appli) : utilisez des proxies applicatifs ou publiez les services derrière un reverse proxy/bastion.
Si vous connectez des utilisateurs/appareils, pas des réseaux : utilisez un overlay avec son propre espace d’adresses et son modèle d’identité.
Ne pas étirer la couche 2 entre bureaux pour « faire d’un coup un seul LAN ». À moins que votre travail inclue la rédaction de postmortems pour le plaisir.

Et une citation pour rester honnête. Voici une idée souvent attribuée à Peter Drucker : « Si vous ne pouvez pas le mesurer, vous ne pouvez pas l’améliorer. » En termes réseau : si vous ne pouvez pas l’observer, vous ne pouvez pas le déboguer.

Patrons de solution qui fonctionnent en production

Patron 1 : NAT / traduction réseau (le gagnant habituel)

C’est la solution de tous les jours. Vous laissez les deux bureaux sur 192.168.0.0/24, mais vous introduisez un sous-réseau traduit pour un côté (ou les deux) lorsque le trafic traverse le lien inter-site.

À quoi ça ressemble

Bureau A LAN : 192.168.0.0/24
Bureau B LAN : 192.168.0.0/24
Traduction pour B vue depuis A : 10.200.0.0/24 (exemple)

Quand un hôte A veut atteindre un hôte B, il cible 10.200.0.x. L’équipement de bord inter-site traduit 10.200.0.x en 192.168.0.x à travers le tunnel, et traduit aussi la source pour que le trafic de retour revienne correctement.

Deux variantes : traduction unidirectionnelle vs bidirectionnelle

Unidirectionnelle (préférée quand possible) : seul le Bureau A initie. A voit B comme 10.200.0.0/24. B n’a peut-être pas besoin de connaître A.
Bidirectionnelle : A voit B comme 10.200.0.0/24 et B voit A comme 10.201.0.0/24. C’est plus de travail mais symétrique et clair pour les ACL.

Avantages

Fonctionne avec le routage normal ; pas de changement des endpoints si vous utilisez DNS et/ou accès basé sur ports.
Compatible avec les tunnels basés sur le routage IPsec, WireGuard, GRE, etc.
Rayon d’impact limité : la traduction ne s’applique qu’entre sites.

Inconvénients

Certaines applications cassent si elles intègrent des IP dans les payloads (SIP, anciens systèmes de licences, certains cas SMB).
Complexité opérationnelle : le dépannage du NAT exige de la rigueur et des logs.
Les équipes sécurité n’aiment parfois pas « cacher » des adresses — ce n’est pas du camouflage, c’est du remappage.

À éviter : du SNAT ad hoc « parce que ça marche ». Utilisez un mappage déterministe et documenté (netmap ou 1:1 quand c’est possible). Le NAT par surcharge aléatoire sur un tunnel est une future note d’incident.

Patron 2 : proxys applicatifs (sérieux, efficaces, limités)

Si le but réel est « les utilisateurs du bureau A ont besoin de l’application de compta au bureau B » et rien d’autre, ne construisez pas une fusion réseau. Publiez l’application correctement.

Exemples :

Reverse proxy pour applications HTTP(S) (Nginx/HAProxy) dans une DMZ ou réseau de services.
Passerelle RDP / bastion pour quelques serveurs Windows.
Accès fichiers via un service dédié (SFTP/HTTPS) au lieu de SMB complet entre sites.

Cela évite entièrement le chevauchement de sous-réseaux : les clients se connectent à une IP/nom unique atteignable, pas à des hôtes internes au hasard.

Patron 3 : réseaux overlay (WireGuard, « Zero Trust », mesh)

Les overlays attribuent leur propre espace d’adresses (souvent 100.64.0.0/10 de type CGNAT ou un 10.x dédié), et ils routent le trafic selon l’identité et la politique plutôt que « est-ce sur mon LAN ».

Utile quand :

Vous avez besoin de connectivité appareil-à-appareil, pas sous-réseau-à-sous-réseau.
Vous ne contrôlez pas proprement les routeurs de bord (CPE opérateur géré, pare-feu tiers, politique).
Vous souhaitez un déploiement progressif : ajouter des endpoints au fil du temps.

Cependant : un overlay ne résout pas automatiquement « je veux que chaque imprimante voie chaque portable ». Il résout « certains endpoints peuvent atteindre certains endpoints », ce qui est généralement ce que vous voulez réellement quand vous cessez de demander « un VPN ».

Patron 4 : VRF et segmentation L3 (niveau entreprise)

Si vos routeurs/switches supportent les VRF (ou des instances de pare-feu/VDOM), vous pouvez garder les deux réseaux 192.168.0.0/24 séparés en les plaçant dans des tables de routage distinctes. Ensuite vous ferez des fuites de routes ou du NAT entre VRF à des points contrôlés.

C’est le modèle le plus propre quand vous intégrez de nombreux sites qui se chevauchent (ça arrive lors d’acquisitions). C’est aussi le plus susceptible d’être mal implémenté si votre équipe n’a pas déjà géré des VRF en production. L’outillage et l’observabilité doivent être présents : routes par VRF, politiques firewall par VRF, et diagrammes clairs.

Patron 5 : pontage/étirement L2 (la section « à ne pas faire »)

Quelqu’un proposera « juste pontonner les réseaux » pour en faire un seul LAN. Cela signifie étendre les domaines de broadcast (ARP, DHCP, multicast) sur un lien WAN. Le problème de chevauchement ne disparaît pas ; il se transforme en chaos.

Blague n°2 : étirer la couche 2 entre bureaux, c’est comme brancher votre datacenter sur une multiprise du magasin du coin. Techniquement, ça fournit de l’électricité.

Un WAN n’est pas un LAN. Gardez-le routé. Si vous devez faire du L2 pour un besoin legacy, faites-le avec confinement explicite (EVPN/VXLAN, contrôle des tempêtes, DHCP guard) et un plan de retour en arrière testé en étant bien réveillé.

Procédure de diagnostic rapide

Quand la connectivité échoue entre sous-réseaux qui se chevauchent, les gens perdent des heures à regarder l’état du tunnel. Ne le faites pas. Votre goulot d’étranglement est généralement l’une des trois choses : (1) décision de routage de l’hôte, (2) inadéquation de la politique de traduction, (3) chemin de retour/état ACL. Voici l’ordre qui révèle la vérité rapidement.

1) Confirmez ce que l’hôte essaie de faire (on-link vs routé)

Depuis un client au bureau A, vérifiez la route vers l’IP cible (ou le nom) qu’il utilise.
S’il croit que la destination est « link-local » (même /24), il fera de l’ARP et n’atteindra jamais la gateway.

2) Confirmez que l’équipement de bord voit les paquets et applique le NAT prévu

Vérifiez les compteurs hit du pare-feu/NAT.
Utilisez une capture de paquets sur les interfaces inside et tunnel pour prouver la traduction.

3) Confirmez que le chemin de retour est symétrique

Recherchez des réponses qui sortent par la mauvaise interface.
Vérifiez les entrées de conntrack/table d’état et la NAT inverse.

4) Ensuite seulement suspectez le tunnel ou le MTU

La plupart des cas « le VPN est up mais rien ne marche » sont des problèmes de politique/NAT/route, pas de crypto.
Si vous observez une connectivité partielle (ICMP ok, TCP bloque), regardez MTU/MSS et la fragmentation.

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

Les tâches suivantes supposent des gateways/hôtes basés sur Linux pour la démonstration car les commandes sont explicites et vérifiables. Les mêmes concepts se mappent sur les firewalls et routeurs, mais avec des interfaces différentes.

Tâche 1 : Identifier le sous-réseau local et la passerelle sur un client

cr0x@server:~$ ip -4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.0.23/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever

Ce que cela signifie : l’hôte est dans 192.168.0.0/24. Toute destination 192.168.0.x apparaîtra « locale » au noyau.

Décision : si vous avez besoin que cet hôte atteigne un hôte distant également numéroté 192.168.0.x, vous devez utiliser une adresse de destination différente (traduite/overlay/proxy). N’essayez pas de router 192.168.0.0/24 vers le tunnel depuis cet hôte ; il ne choisira jamais cette route.

Tâche 2 : Prouver que l’hôte fera de l’ARP au lieu de router

cr0x@server:~$ ip route get 192.168.0.50
192.168.0.50 dev eth0 src 192.168.0.23 uid 1000
    cache

Ce que cela signifie : c’est on-link (dev eth0), pas via une gateway.

Décision : n’utilisez pas 192.168.0.50 comme adresse « distante » depuis ce LAN. Utilisez un préfixe traduit comme 10.200.0.50 (avec NAT en bordure), ou un nom DNS qui résout vers cette adresse traduite.

Tâche 3 : Vérifier la table ARP après un ping échoué

cr0x@server:~$ ping -c 1 192.168.0.50
PING 192.168.0.50 (192.168.0.50) 56(84) bytes of data.

--- 192.168.0.50 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
cr0x@server:~$ ip neigh show to 192.168.0.50
192.168.0.50 dev eth0 INCOMPLETE

Ce que cela signifie : l’hôte a fait de l’ARP sur le LAN local, n’a reçu aucune réponse, et n’a jamais tenté la passerelle VPN.

Décision : toute « correction » qui se concentre sur le tunnel est prématurée. L’endpoint n’envoie pas le trafic vers le tunnel.

Tâche 4 : Valider que le préfixe traduit est routable via la passerelle

cr0x@server:~$ ip route get 10.200.0.50
10.200.0.50 via 192.168.0.1 dev eth0 src 192.168.0.23 uid 1000
    cache

Ce que cela signifie : le trafic vers 10.200.0.0/24 ira vers la gateway (192.168.0.1), qui pourra ensuite le NAT/tunneler.

Décision : procédez avec le NAT de bord et la politique de tunnel pour 10.200.0.0/24 comme « remote B ». Si cette route manque, ajoutez-la via l’option DHCP 121/routes sans classe, ou annoncez-la via votre protocole de routage interne.

Tâche 5 : Sur la passerelle, confirmer que le forwarding IP est activé

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

Ce que cela signifie : la passerelle routage des paquets entre interfaces.

Décision : si c’est 0, rien d’autre n’a d’importance. Activez-le et assurez-vous que cela persiste. S’il est 1, passez au routage et aux règles NAT.

Tâche 6 : Vérifier les routes sur la passerelle pour le sous-réseau traduit et le tunnel

cr0x@server:~$ ip route show
default via 203.0.113.1 dev wan0
10.200.0.0/24 dev wg0 scope link
192.168.0.0/24 dev lan0 scope link src 192.168.0.1

Ce que cela signifie : la passerelle croit que 10.200.0.0/24 est joignable via l’interface tunnel (wg0).

Décision : si 10.200.0.0/24 manque ou pointe ailleurs, corrigez le routage d’abord. Les règles NAT ne sauveront pas un routage erroné.

Tâche 7 : Vérifier les AllowedIPs du pair WireGuard (point de défaillance courant)

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

peer: p9nS...redacted...
  endpoint: 198.51.100.10:51820
  allowed ips: 10.200.0.0/24
  latest handshake: 41 seconds ago
  transfer: 120.33 KiB received, 98.11 KiB sent

Ce que cela signifie : le pair est up et le tunnel acceptera/route 10.200.0.0/24.

Décision : si AllowedIPs n’inclut pas votre préfixe traduit, le noyau va jeter ou mal router le trafic. Corrigez AllowedIPs, puis retestez.

Tâche 8 : Inspecter les règles NAT (nftables) et confirmer l’incrémentation des compteurs

cr0x@server:~$ sudo nft list ruleset
table ip nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    iifname "lan0" ip daddr 10.200.0.0/24 dnat to 192.168.0.0/24
  }
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "wg0" ip saddr 192.168.0.0/24 snat to 10.201.0.1
  }
}

Ce que cela signifie : l’entrée venant du LAN destinée à 10.200.0.0/24 est DNATée vers 192.168.0.0/24. En sortie vers le tunnel, le SNAT rend la source unique pour que le côté distant puisse retourner le trafic.

Décision : si vous ne faites que du DNAT sans SNAT correspondant (ou vice versa), les réponses disparaîtront probablement dans le mauvais LAN. Utilisez une traduction symétrique sauf si vous avez un design asymétrique validé.

Tâche 9 : Utiliser conntrack pour confirmer l’état et la traduction

cr0x@server:~$ sudo conntrack -L | head
tcp      6 431999 ESTABLISHED src=192.168.0.23 dst=10.200.0.50 sport=51544 dport=445 src=192.168.0.50 dst=10.201.0.1 sport=445 dport=51544 [ASSURED] mark=0 use=1

Ce que cela signifie : conntrack montre le flux original (192.168.0.23 -> 10.200.0.50) et le tuple traduit vers l’extrémité distante (... dst=10.201.0.1 comme source SNAT).

Décision : si l’état n’apparaît jamais, le trafic n’atteint pas la passerelle ou est bloqué par la politique du pare-feu avant NAT. Si l’état apparaît mais pas de trafic de retour, dépannez le routage/NAT et les politiques côté distant.

Tâche 10 : Capture de paquets sur interfaces LAN et tunnel pour prouver le comportement NAT

cr0x@server:~$ sudo tcpdump -ni lan0 host 192.168.0.23 and host 10.200.0.50
IP 192.168.0.23.51544 > 10.200.0.50.445: Flags [S], seq 123456, win 64240, length 0
cr0x@server:~$ sudo tcpdump -ni wg0 host 192.168.0.50 and port 445
IP 10.201.0.1.51544 > 192.168.0.50.445: Flags [S], seq 123456, win 64240, length 0

Ce que cela signifie : vous voyez la destination originale sur le LAN (10.200.0.50) et le paquet post-NAT sur le tunnel (dst 192.168.0.50, src 10.201.0.1).

Décision : si la capture LAN montre du trafic mais pas la capture tunnel, le NAT ou le routage est erroné sur la passerelle. Si le tunnel montre l’aller mais pas le retour, le côté distant ne retourne pas (politique, routage ou NAT asymétrique).

Tâche 11 : Vérifier le reverse path filtering (rp_filter) sur des gateways Linux

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.wg0.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.wg0.rp_filter = 1

Ce que cela signifie : un reverse path filtering strict peut jeter des paquets arrivant sur une interface qui ne correspond pas à la route de retour selon le noyau. Le NAT plus les tunnels et les interfaces multiples est précisément l’endroit où cela pose problème.

Décision : pour des gateways faisant du NAT sur des tunnels, mettez rp_filter en mode loose (2) ou désactivez-le par interface, mais seulement en comprenant les implications et en compensant par la politique du pare-feu. Si vous voyez un trafic unidirectionnel mystérieux, c’est un suspect majeur.

Tâche 12 : Tester les problèmes MTU/MSS (classique « le VPN est up mais TCP bloque »)

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

--- 10.200.0.50 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 21.7/21.9/22.1/0.2 ms

Ce que cela signifie : avec DF activé, une charge utile de 1380 octets fonctionne. Si ceci échoue alors que des pings plus petits réussissent, vous avez un problème MTU sur le chemin/tunnel.

Décision : limitez le MSS TCP sur la bordure du tunnel et/ou réduisez le MTU du tunnel. Ne « réparez » pas cela en désactivant globalement PMTUD ; c’est ainsi que vous créez de nouveaux problèmes.

Tâche 13 : Vérifier que les réponses DNS correspondent à votre plan de traduction

cr0x@server:~$ dig +short fileserver.officeb.example
10.200.0.50

Ce que cela signifie : les clients sont dirigés vers l’adresse traduite, pas vers l’adresse réelle ambiguë du LAN.

Décision : si le DNS renvoie 192.168.0.50 pour un service distant, les clients feront de l’ARP et échoueront. Corrigez le DNS (split-horizon ou forwarding conditionnel) pour que les noms résolvent vers des adresses traduites/overlay.

Tâche 14 : Confirmer que la politique du pare-feu ne laisse pas tomber silencieusement le trafic traduit

cr0x@server:~$ sudo nft list chain inet filter forward
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "lan0" oifname "wg0" ip daddr 192.168.0.0/24 tcp dport { 22, 445, 3389 } accept
  }
}

Ce que cela signifie : la politique par défaut est drop, et seuls certains ports sont autorisés du LAN vers le tunnel vers le LAN distant après DNAT.

Décision : si vous vouliez un accès large mais n’avez autorisé que quelques ports, vous verrez des échecs sélectifs. Ajustez la politique pour correspondre aux besoins. Et gardez-la stricte. « Any-any entre sites » est la façon dont les malwares internes voyagent fréquemment.

Trois mini-histoires d’entreprise

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a acquis une plus petite et avait besoin d’une « connectivité rapide » pour les systèmes financiers. Les deux bureaux étaient en 192.168.0.0/24, mais personne ne l’a remarqué parce que le ticket disait « configurer un VPN site-à-site, les sous-réseaux sont standards ». L’équipe réseau a configuré un tunnel IPsec basé sur des politiques avec des domaines de chiffrement locaux et distants tous deux réglés sur 192.168.0.0/24. Le tunnel s’est levé. Le tableau de bord était vert. Tout le monde est parti chez soi.

Le lendemain matin, la comptabilité ne pouvait plus atteindre rien. La première supposition : « le VPN est down. » Ce n’était pas le cas. La deuxième supposition : « problème DNS. » Pas vraiment. Le problème réel était banal : les clients du bureau A essayaient d’accéder à un serveur du bureau B par IP (192.168.0.40), et chacun d’eux faisait de l’ARP localement. Le helpdesk signalait « no route to host » sur les machines Linux et « request timed out » sur Windows. Les ingénieurs ont contemplé les SAs IPsec et les timers de rekey pendant deux heures.

La percée est venue d’une capture de paquets sur un switch client : des requêtes ARP pour 192.168.0.40 répétées comme un métronome. Aucune implication de la gateway par défaut. Aucun trafic VPN. Le tunnel était innocent.

Ils ont corrigé cela en déployant du NAT en bordure : le bureau B est devenu 10.200.0.0/24 vu depuis le bureau A, et les noms DNS des services B résolvaient vers ces IP traduites. L’incident s’est terminé discrètement. Le postmortem n’était pas « IPsec est dur. » C’était « nous avons supposé l’unicité sans vérifier. »

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre organisation a connecté deux sites qui se chevauchent par traduction et les choses fonctionnaient en grande partie. Puis quelqu’un a voulu « optimiser la latence » en ajoutant un second tunnel sur un lien ISP moins cher et en activant ECMP entre les tunnels. Le but était le partage de charge. La réalité a été le pulvérisation des états conntrack et NAT sur deux chemins sans coordination.

Certaines flows sont passées par le tunnel A, ont été NATées, et les réponses sont revenues par le tunnel B. Selon le pare-feu, ces réponses étaient soit rejetées comme état invalide, soit acceptées puis retranslatées incorrectement. Les utilisateurs ont rapporté des symptômes aléatoires : copies de fichiers échouant à 37 %, sessions RDP gelant, et applications web se « déconnectant » en plein clic.

L’équipe a d’abord accusé le ISP moins cher pour la perte de paquets. Il y avait un peu de perte, certes. Mais le cœur du problème était l’état de traduction d’état traversant des chemins asymétriques. Les tunnels étaient sains ; l’architecture ne l’était pas.

La correction n’a pas été dramatique : épingler les flux (routage basé sur politique ou marquage de connexion) pour que les deux directions d’une connexion restent sur un même tunnel, ou fonctionner en actif/standby plutôt qu’en ECMP pour le trafic NAT stateful. L’« optimisation » est devenue une régression de stabilité parce que personne n’a demandé si le système pouvait être sans état. Ce n’était pas le cas.

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

Une entreprise globale avait l’habitude : avant tout changement de connectivité inter-site, ils produisaient une « Fiche d’identité des adresses » d’une page. Elle listait chaque sous-réseau pertinent, la plage de traduction, le comportement DNS et qui en était responsable. C’était ennuyeux. Cela a aussi évité une pile d’incidents.

Pendant un déménagement de bureau, un prestataire a reconfiguré un routeur de succursale et a accidentellement changé la plage DHCP de 192.168.1.0/24 à 192.168.0.0/24 parce que « c’est ce qu’on utilise toujours ». Dans la nuit, des imprimantes et quelques postes ont obtenu de nouvelles baux. Le design de traduction site-à-site s’est alors chevauché avec la réalité locale, et le premier signalement a été « le serveur de fichiers distant est down ».

L’ingénieur d’astreinte a sorti la Fiche d’identité des adresses, a vu que 192.168.0.0/24 était réservé pour la sémantique de traduction dans cette région, et a immédiatement suspecté une dérive du sous-réseau local. Une vérification de cinq minutes des logs DHCP l’a confirmé. Ils ont remis la portée DHCP, vidé quelques baux, et la « panne VPN » a disparu.

Pas d’héroïsme. Pas d’appels fournisseur. Juste un document ennuyeux et la discipline pour le tenir à jour. En exploitation, l’ennuyeux est souvent le résultat le plus sophistiqué.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom : « Le VPN est up, mais je ne peux pas pinguer le 192.168.0.x distant »

Cause racine : le client considère 192.168.0.x comme on-link et fait de l’ARP local ; le trafic n’entre jamais dans le tunnel.

Correction : ne ciblez pas directement le sous-réseau superposé du site distant. Utilisez un préfixe traduit (p. ex. 10.200.0.0/24), une IP overlay, ou une adresse proxy. Ajustez le DNS en conséquence.

2) Symptom : « Une seule direction fonctionne » (A atteint B, B n’atteint pas A)

Cause racine : traduction asymétrique ou appairage SNAT/DNAT manquant ; le trafic de retour est routé localement côté distant.

Correction : implémentez un mappage symétrique ou assurez-vous que le côté distant a une route vers la source traduite. Vérifiez les entrées conntrack et les captures des deux côtés.

3) Symptom : « Certains ports fonctionnent, SMB casse, RDP se réinitialise »

Cause racine : mismatch de politique firewall, modules helper, ou problèmes MTU/MSS ; parfois le NAT ré-injecte des flux inattendus.

Correction : confirmez les ports autorisés dans la politique forward, testez PMTUD avec des pings DF, clamp MSS sur la bordure du tunnel, et évitez des ALGs trop « intelligents » à moins d’en avoir besoin.

4) Symptom : « Ça marche quelques minutes, puis s’arrête jusqu’au redémarrage du tunnel »

Cause racine : timeout d’état NAT, routage asymétrique, ou ECMP sur des dispositifs stateful ; parfois une rekey modifie le chemin.

Correction : forcez un routage symétrique, augmentez les timeouts pertinents si justifié, et évitez le partage de charge sans synchronisation d’état.

5) Symptom : « Seuls quelques hôtes peuvent se connecter ; d’autres non »

Cause racine : chevauchement à plus petite échelle (routes statiques sur certains clients, VLAN multiples), IP dupliquées, ou conflits de scope DHCP.

Correction : inventaire des adresses. Vérifiez les routes client et le comportement ARP. Verrouillez les scopes DHCP et assurez-vous que les préfixes traduits ne sont pas utilisés localement.

6) Symptom : « Le DNS résout, mais les connexions vont vers la mauvaise machine »

Cause racine : DNS split-horizon mal configuré ; le nom interne résout vers un 192.168.0.x local au lieu de vers une IP traduite/overlay.

Correction : implémentez un forwarding conditionnel ou des vues pour que chaque bureau obtienne la bonne réponse. Pour les services partagés, préférez des noms qui résolvent vers des adresses non ambiguës.

Listes de vérification / plan étape par étape

Plan étape par étape : connecter deux /24 qui se chevauchent avec NAT sur tunnel

Choisir des préfixes de traduction qui n’existent nulle part ailleurs. Ne prenez pas un autre « mignon » par défaut comme 192.168.1.0/24. Utilisez quelque chose d’évidemment « virtuel », comme 10.200.0.0/24 pour le Bureau B et 10.201.0.0/24 pour le Bureau A (vu depuis B).
Décider si vous avez besoin d’initiation unidirectionnelle ou bidirectionnelle. Si seuls quelques services à B doivent être accessibles depuis A, l’unidirectionnel peut suffire.
Choisir le substrat de connectivité : IPsec basé sur le routage, WireGuard, GRE over IPsec, etc. Le mode route-based facilite la raison sur le NAT.
Ajouter des routes : sur la gateway du Bureau A, routez 10.200.0.0/24 vers le tunnel. Sur la gateway du Bureau B, routez 10.201.0.0/24 vers le tunnel (si bidirectionnel).
Implémenter un NAT déterministe :
- DNAT 10.200.0.x vers 192.168.0.x au bord du Bureau B (ou au bord du Bureau A selon le design).
- SNAT les sources vers une source traduite que le côté distant peut retourner sans ambiguïté.
Mettre à jour le DNS : faire résoudre les services distants vers des IP traduites. Utilisez split-horizon si le même nom doit résoudre différemment selon le site.
Contrainte d’accès par politique firewall : autorisez uniquement les ports requis. Commencez restreint, élargissez avec intention.
Valider avec captures à trois points : LAN client, côté LAN de la gateway locale, côté tunnel de la gateway.
Renforcer MTU/MSS avant que les utilisateurs ne se plaignent. Clamp MSS sur la bordure du tunnel si possible.
Consigner le mappage dans un endroit où les gens le trouveront (ticket + runbook). La traduction est un choix de conception, pas un secret.
Monitoring : ajouter des contrôles de santé du tunnel, compteurs de hit des règles NAT, et des transactions synthétiques (p. ex. TCP connect vers l’IP/port du service distant).
Plan de rollback : être prêt à désactiver proprement les règles NAT et les routes. N’improvisez pas sous pression.

Checklist opérationnelle : avant de déclarer « terminé »

Chaque service inter-site a un nom qui résout vers une adresse non ambiguë depuis chaque bureau.
Les mappings NAT sont déterministes et documentés (quelle plage traduite mappe quelle plage réelle).
Le trafic de retour est prouvé par des captures ; pas supposé.
Les politiques firewall suivent le principe du moindre privilège, avec règles allow explicites et logs des drops pendant le déploiement.
MTU/MSS testés par pings DF et un vrai transfert TCP.
Vous pouvez expliquer la conception à un ingénieur fatigué à 3 h du matin avec un seul diagramme.

FAQ

1) Puis-je résoudre le chevauchement de sous-réseaux uniquement avec des routes statiques ?

Non. Si un hôte croit que la destination est on-link (même sous-réseau), il fait de l’ARP et ne consulte jamais votre route statique ingénieuse. Vous devez changer l’identité de destination (traduction/overlay/proxy) ou modifier le masque d’hôte (ce qui revient à renuméroter déguisé).

2) Et si je change un bureau en /23 ou /25 pour « les séparer » ?

C’est une renumérotation partielle et cela provoque généralement plus d’effets secondaires qu’on ne l’imagine : scopes DHCP, ACL, configurations d’imprimantes et hypothèses codées en dur. Ça peut servir d’étape, mais ne prétendez pas que c’est indolore.

3) Le NAT entre sites est-il « mauvaise pratique » ?

C’est un compromis, pas un péché. Pour des réseaux qui se chevauchent, le NAT est souvent le chemin le moins risqué vers la connectivité sans toucher les endpoints. La mauvaise pratique est un NAT non documenté et incohérent qui transforme le dépannage en archéologie.

4) Quelle plage traduite dois-je utiliser ?

Choisissez quelque chose peu susceptible d’entrer en collision avec des réseaux existants ou futurs. Beaucoup d’organisations réservent un bloc comme 10.200.0.0/16 pour les traductions. Le choix exact importe moins que de le rendre globalement unique dans votre environnement et de l’écrire.

5) Les partages SMB fonctionneront-ils via NAT ?

Généralement oui, si MTU/MSS est correct et que les pare-feu stateful ne les altèrent pas. Mais SMB est sensible à la latence et à la perte de paquets, et il aime les connexions longues. Testez des transferts réels, pas seulement des pings.

6) Dois-je traduire source et destination ?

Dans la plupart des cas de sous-réseaux qui se chevauchent, oui, au moins pour la direction initiatrice. Un seul DNAT échoue souvent parce que le côté distant route les réponses localement (puisque la source semble être sur son LAN). La traduction symétrique rend les chemins de retour non ambigus.

7) Les overlays (comme WireGuard) peuvent-ils éviter complètement le NAT ?

Souvent oui. Si chaque endpoint reçoit une IP overlay dans une plage unique, les endpoints parlent via les adresses overlay, pas les adresses LAN qui se chevauchent. Mais si vous voulez « chaque hôte de A atteigne chaque hôte de B par leurs IP existantes », les overlays n’accorderont pas ce souhait sans traduction ou proxies supplémentaires.

8) Et si je n’ai besoin d’accéder qu’à quelques serveurs dans l’autre bureau ?

Utilisez un proxy ou publiez ces services via un petit réseau de services avec adressage unique. C’est moins de pièces mobiles qu’une traduction réseau complète, et plus facile à sécuriser.

9) Comment les VPN cloud gèrent-ils les CIDR qui se chevauchent (AWS/Azure) ?

Ils ne le « gèrent » généralement pas magiquement ; ils exigent que vous utilisiez du NAT/traduction en bordure, ou que vous attribuiez des espaces d’adresses uniques par attachement réseau. Le chevauchement est un problème de topologie, pas une case à cocher fournisseur.

10) Quelle est la solution la plus propre à long terme ?

Renuméroter vers des sous-réseaux uniques, avec un vrai plan d’adressage. Le NAT est un pont parfaitement acceptable (parfois pour des années), mais le modèle d’identité le plus propre à long terme est un adressage unique et un bon routage.

Conclusion : prochaines étapes concrètes

Si vous connectez deux bureaux qui utilisent tous deux 192.168.0.0/24, vous ne luttez pas contre le chiffrement. Vous luttez contre l’ambiguïté. Votre travail est de faire en sorte que les paquets puissent répondre à une question : « Lequel des 192.168.0.50 voulez-vous dire ? »

Étapes pratiques :

Choisissez un préfixe traduit pour un bureau (10.200.0.0/24 est un bon exemple) et réservez-le pour qu’il ne soit pas utilisé localement plus tard.
Décidez du modèle d’accès : portée L3 complète (NAT/VRF) vs portée services (proxy) vs portée appareils (overlay).
Implémentez une connectivité route-based (WireGuard ou IPsec route-based), puis ajoutez un NAT déterministe avec logs et compteurs.
Corrigez le DNS pour que les humains utilisent des noms et que ceux-ci résolvent vers des adresses non ambiguës depuis chaque site.
Exécutez le playbook de diagnostic rapide lors du déploiement, pour être plus rapide lors du inévitable réveil à 2 h du matin.

Le résultat le plus professionnel n’est pas « on a réussi à faire fonctionner ». C’est « on a rendu cela prévisible, observable et facile à expliquer. » C’est ainsi que vous connectez des réseaux qui se chevauchent sans transformer la prochaine astreinte en chasse au trésor.