Sous-réseaux chevauchants entre bureaux : 3 solutions opérationnelles sans renumérotation

Ce que « sous-réseaux chevauchants » casse réellement (et pourquoi)

Les sous-réseaux chevauchants ne sont pas « un problème de routage » en abstraction. C’est un problème de collision de noms avec des conséquences concrètes. Si les deux sites ont 10.10.0.0/16 et que vous essayez de router entre eux, un hôte du Site A ne peut pas distinguer « 10.10.1.20 au Site A » de « 10.10.1.20 au Site B ». Vos routeurs non plus — du moins pas avec la sémantique de routage IP classique.

Ce que vous verrez en production

• Accessibilité asymétrique : A peut parfois atteindre le serveur de B ; les réponses disparaissent parce que le chemin de retour résout vers le jumeau local.
• Mensonges ARP et cache voisin : Sur des extensions L2 (ne le faites pas), des basculements MAC et des journaux « IP dupliquée » apparaissent parce que la même IP existe deux fois.
• Ambiguïté des règles NAT/pare-feu : « Autoriser 10.10.1.0/24 » devient un pile ou face à moins d’être explicite sur quel 10.10.1.0/24 vous parlez.
• Le DNS aggrave le problème : si les deux sites publient des noms internes dans la même zone, vous obtenez des réponses « correctes » qui pointent vers le mauvais jumeau.
• La supervision devient de la fiction : votre NMS ping 10.10.1.20 et pense que le système distant est up — parce qu’il a pingé le système local.

La réponse humaine habituelle est le déni. Le réseau est « up » parce que le tunnel est vert. Mais le chevauchement ne tue pas le tunnel ; il tue le sens. Et les systèmes fonctionnent grâce au sens.

Conseil tranché : N’essayez pas de « forcer le routage à préférer le site distant ». Vous ne pouvez pas résoudre une collision d’espaces de noms avec du routage sans ajouter un nouvel espace de noms (NAT, VRF ou identités overlay).

Playbook de diagnostic rapide (vérifications 1/2/3)

Ceci est le chemin le plus rapide pour identifier le goulot d’étranglement et choisir le correctif le moins pire. Si vous faites ces vérifications dans l’ordre, vous cessez de débattre sur des impressions.

1) Confirmer que le chevauchement est réel (pas seulement un blocage pare-feu)

Choisissez une « IP problématique » et vérifiez si elle existe dans les deux endroits. Contrôlez les tables ARP, les baux DHCP, ou le comportement de ping local.

• Si un hôte ping la « 10.x.x.x distante » même quand le VPN est down, vous n’atteignez rien de distant. Vous touchez le jumeau local.
• Si traceroute n’entre jamais dans le tunnel et reste dans le site, vous routez localement vers le réseau jumeau.

2) Identifier ce qui doit communiquer entre sites (et ce qui peut être ignoré)

Inventoriez les flux : AD, DNS, services fichiers, ERP, VoIP, sous-réseaux imprimantes, RDP/SSH, supervision, réplication de sauvegarde. Puis hiérarchisez selon l’impact métier et la bidirectionnalité requise.

• Protocoles bidirectionnels (SMB, AD, Kerberos, VoIP) supportent moins les rustines.
• Accès unidirectionnel (utilisateurs vers une application web) peut souvent être résolu plus rapidement avec du NAT.

3) Vérifier où la politique peut être appliquée : pare-feu d’entrée, routeur cœur ou hôtes

La meilleure solution dépend de l’endroit où vous pouvez contrôler l’espace de noms et la sélection de routes.

• Si vous contrôlez les deux bords : NAT ou VRF sont généralement les plus rapides.
• Si vous ne contrôlez qu’un seul côté (partenaire, fournisseur, site acquis encore « indépendant ») : le NAT est votre levier.
• Si vous avez besoin d’une mise à l’échelle multi-site future : l’overlay est coûteux mais propre.

Une fois que vous savez (a) l’étendue du chevauchement, (b) les flux requis et (c) vos points de contrôle, vous pouvez choisir une solution sans transformer votre VPN en maison hantée.

Trois solutions opérationnelles (sans reconstruction)

Les trois solutions ajoutent une nouvelle frontière d’espace de noms pour que les adresses identiques cessent de se heurter. Elles diffèrent par l’endroit où vit la frontière et par la dette opérationnelle que vous acceptez.

Matrice de décision (quoi choisir et quand)

• Choisissez NAT lorsque vous avez besoin de résultats rapides, que vous pouvez tolérer la traduction d’adresses, et que votre objectif principal est « les utilisateurs ici atteignent les serveurs là-bas ».
• Choisissez VRF lorsque vous voulez une séparation propre, que vous disposez de matériel de routage adéquat, et que vous souhaitez minimiser les bizarreries de traduction.
• Choisissez un overlay lorsque vous avez besoin de connecter de nombreux sites ou d’intégrer cloud/on-prem proprement et que vous en avez fini avec le bricolage.

Vous pouvez aussi les combiner. Dans la réalité, vous le ferez souvent. Évitez simplement d’empiler des abstractions sans réfléchir. Chaque couche ajoutée est un endroit supplémentaire où les mensonges de 3 h du matin peuvent se cacher.

Solution 1 : NAT (alias faire paraître l’autre site différent)

Le NAT est l’instrument brutal qui fonctionne parce qu’il change l’espace de noms. Si le Site B a 10.10.0.0/16 en conflit avec le Site A 10.10.0.0/16, vous pouvez mapper le Site B vers une plage « virtuelle » — par exemple 172.20.10.0/24 ou 100.64.10.0/24 — uniquement à travers le tunnel. Pour le Site A, le Site B n’est plus 10.10.0.0/16. Problème résolu, du moins pour le routage IP.

Deux modèles de NAT qui fonctionnent réellement

• NAT statique bidirectionnel (1:1 ou many:many) : Idéal quand des serveurs doivent être joignables des deux côtés avec des adresses stables.
• SNAT côté source dans une seule direction : Idéal quand un seul côté initie les connexions et que vous pouvez laisser l’autre côté essentiellement ignorant.

Où placer le NAT : sur l’équipement périphérique participant aussi au VPN (pare-feu/routeur). Ne saupoudrez pas de règles NAT sur des sauts internes aléatoires sauf si vous aimez diagnostiquer des tables d’état sur plusieurs boîtes.

Ce que le NAT casse (préparez-vous)

• ACL et listes blanches basées sur IP : les systèmes distants verront des adresses traduites. Mettez à jour les politiques ou utilisez des mappages cohérents.
• Protocoles qui intègrent des IP : certaines applications legacy, SIP sans helpers adaptés, certains modes FTP. Les piles modernes s’en sortent mieux, mais n’en faites pas une supposition.
• Cas limites Kerberos/AD : AD peut fonctionner à travers NAT, mais il faut veiller à la résolution de noms, aux SPN et à la topologie de site. Si vous pouvez éviter le NAT au milieu de la réplication DC-à-DC, faites-le.

Blague #1 : Le NAT, c’est comme mettre des étiquettes sur des jumeaux identiques — utile jusqu’à ce que quelqu’un décide d’échanger les chemises pour s’amuser.

Quand le NAT est la meilleure réponse

Si vous êtes en fusion et que vous avez besoin d’« accès à une poignée de systèmes » plus que d’« une intégration d’entreprise parfaite », le NAT est votre ami. Il achète du temps. Le temps que vous dépenserez ensuite pour renumérotation, segmentation ou un overlay convenable.

Ce qu’il faut éviter : un « NAT temporaire » qui devient permanent sans documentation. Si vous faites du NAT, traitez-le comme un produit : mappages déterministes, sous-réseaux cohérents, journalisation et plan de retour arrière.

Solution 2 : VRF / segmentation (garder les deux vérités séparées)

Les VRF (Virtual Routing and Forwarding) vous donnent plusieurs tables de routage sur le même matériel. Cela signifie que vous pouvez avoir 10.10.0.0/16 dans VRF-A et 10.10.0.0/16 dans VRF-B, et ils ne se percuteront pas parce qu’ils vivent dans des univers de routage différents.

Les VRF sont la solution « mature » quand vous contrôlez le routage et que vous voulez préserver les adresses IP d’origine de bout en bout. Elles sont aussi la bonne solution quand vous avez besoin de multiples locataires chevauchants (commun chez les MSSP, grandes entreprises ou fusions en transition).

Deux schémas de déploiement VRF

• VRF à la périphérie (recommandé) : Placez le site distant dans sa propre VRF sur le routeur/pare-feu VPN. Importez/exportez seulement les routes nécessaires.
• VRF au cœur (changement plus important) : Si le chevauchement existe dans des cœurs de campus, vous devrez peut-être déployer des VRF plus proches de la distribution pour éviter les fuites.

Les VRF ne résolvent pas tout magiquement

Les VRF isolent le routage, pas l’identité. Si vous avez encore besoin que des applications dans VRF-A parlent à des hôtes ayant des adresses identiques dans VRF-B, il vous faut un mécanisme de pont : fuite de routes avec NAT, un proxy, ou des changements au niveau applicatif. VRF est d’abord une stratégie de confinement, ensuite une stratégie de connectivité.

Conseil tranché : Si votre objectif est « connecter deux sites chevauchants », la VRF seule ne fonctionnera pas à moins d’introduire aussi de la traduction ou des proxys applicatifs. Si votre objectif est « connecter les deux sites à des services partagés sans les fusionner », la VRF est parfaite. En réalité d’entreprise, ce second objectif revient plus souvent qu’on ne l’admet.

Modes de défaillance à anticiper

• Erreurs de fuite de routes : une route par défaut fuitée et vous avez construit un backhaul surprise.
• Dérive des politiques de sécurité : les pare-feu doivent être VRF-aware. Si vos outils ne sont pas VRF-aware, les auditeurs apprendront de nouveaux mots.
• Lacunes des outils opérationnels : NMS, logs de flux et captures doivent être scindés par VRF sinon vous dépannerez des fantômes.

Solution 3 : Réseaux overlay (router au-dessus du désordre)

Les overlays donnent aux endpoints un nouvel espace d’adresses (ou une nouvelle identité) indépendant de l’underlay. Pensez VXLAN/EVPN, adressage de fabric SD-WAN, maillage WireGuard avec « overlay IPs » attribuées, ou même des réseaux applicatifs L3-only. L’idée est une identité cohérente entre sites sans se soucier des sous-réseaux underlay.

Si le NAT est un tournevis et la VRF un tiroir à outils, un overlay est tout un établi. Ce n’est pas la solution la plus rapide, mais c’est celle qui monte en charge quand vous ajoutez plus de sites, plus de clouds et plus d’exceptions « temporaires ».

Schémas overlay réalistes sans reconstruction

• Sous-réseau overlay dédié pour services inter-sites : vous n’overlayez pas tout — seulement les serveurs qui doivent être joignables entre sites. Chaque serveur reçoit une IP supplémentaire (ou une loopback) dans la plage overlay.
• Passerelles de service : au lieu de toucher chaque endpoint, déployez des passerelles par site qui annoncent des routes overlay et proxys/route vers les services locaux.
• SD-WAN avec segmentation : beaucoup de produits SD-WAN supportent les LAN underlay chevauchants en les mappant dans des segments VPN/VRF et en annonçant des routes « virtuelles » non chevauchantes.

Ce que les overlays vous coûtent

• Complexité opérationnelle : plan de contrôle, chiffrement, MTU, surcharge d’encapsulation et télémétrie. Vous ajoutez des éléments mobiles.
• Fragilité MTU : l’encapsulation réduit la MTU effective. Si vous ne testez pas le PMTUD, vous casserez quelque chose « au hasard ».
• Exigences de compétences : votre équipe doit être à l’aise pour lire des tables de routage, des annonces EVPN ou l’état des peers du maillage — pas seulement « le tunnel est up ».

Blague #2 : Les overlays sont super jusqu’à ce que quelqu’un dise « c’est juste du réseau » et change la MTU à un endroit.

Pourquoi les overlays sont souvent la meilleure réponse long terme

Parce qu’ils découplent l’intégration métier de l’hygiène IP. Vous pouvez fusionner des entreprises, déplacer des workloads et survivre à des LAN legacy imparfaits tout en fournissant une connectivité cohérente pour l’essentiel. Si vous construisez une plateforme multi-site (pas seulement une fusion ponctuelle), les overlays réduisent la quantité de « cas par site » que vous devez gérer.

Trois mini-histoires d’entreprise du terrain

1) L’incident causé par une mauvaise hypothèse : « 10.50.0.0/16 est unique. Sûrement. »

L’équipe d’intégration a connecté deux bureaux via IPsec. Les deux côtés avaient des feuilles de calcul bien tenues. Les deux parties juraient que leurs plages internes étaient « uniques ». Le tunnel est monté ; la supervision est passée au vert. Tout le monde est rentré tôt, ce qui est toujours suspect.

Lundi matin, le help desk a reçu des rapports que la finance ne pouvait pas joindre un serveur de reporting. Le serveur était « up », les journaux du pare-feu montraient des acceptations, et l’équipe applicative insistait que le service n’avait pas changé. L’équipe réseau a lancé un traceroute depuis un poste. Il n’a jamais atteint le VPN. Il est resté local et s’est terminé sur un SVI de switch. Signe classique : la route vers 10.50.12.40 était interne, pas distante.

Il s’est avéré que les deux sites utilisaient 10.50.0.0/16. Le serveur de reporting se trouvait au Site B, mais le Site A avait une imprimante avec la même IP dans un VLAN oublié. L’imprimante n’était même pas cassée ; elle répondait juste à l’ICMP comme un bonimenteur joyeux. Le test « ça ping » était inutile.

La réparation n’a rien d’héroïque. Ils ont ajouté un mappage NAT pour la poignée de serveurs critiques du Site B vers une plage de translation 172.20.50.0/24, mis à jour le DNS pour ces services, et ont arrêté d’essayer de router le chevauchement directement. La leçon retenue : les hypothèses sur l’unicité des IP vieillissent mal, surtout après des acquisitions.

2) L’optimisation qui a mal tourné : compresser les routes et « simplifier » les politiques

Une autre entreprise a voulu être maligne. Elle avait du chevauchement dans 192.168.1.0/24 et 192.168.2.0/24 à travers plusieurs agences. Au lieu de traductions soigneuses par sous-réseau, ils ont résumé les politiques et routes pour « autoriser 192.168.0.0/16 à travers le tunnel ». Le débit VPN s’est amélioré légèrement. Leur demande de changement a été approuvée en un temps record, ce qui aurait dû être un deuxième indice.

En quelques heures, des bizarreries : des sessions RDP se connectaient aux mauvaises machines. Des scanners d’actifs « trouvaient » des appareils qui n’étaient pas là. Pire, une agence pouvait maintenant atteindre les interfaces admin d’une autre agence parce que la règle générale le permettait. Rien n’a explosé immédiatement, et c’est souvent comme ça que les problèmes de sécurité s’introduisent — silencieusement.

Le retour de bâton n’était pas que la summarisation soit toujours mauvaise. C’est que la summarisation à travers des espaces chevauchants retire les derniers éléments de spécificité que vous aviez. Ils avaient échangé la justesse contre la commodité. Quand il y a chevauchement, la spécificité est votre ceinture de sécurité.

Ils ont fait un rollback, puis reconstruit avec des pools NAT explicites par agence et des objets pare-feu explicites par sous-réseau traduit. Ça a pris plus de temps. Ça a aussi arrêté le phénomène de « RDP téléporté », ce qui n’est pas une fonctionnalité.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : traduction déterministe + banc de test

Dans une grande entreprise, le plan de merger était réaliste : « Nous ne renuméroterons aucune des deux sociétés pendant au moins 18 mois. » Ils ont implémenté un schéma NAT déterministe : chaque site a reçu un /16 traduit issu de 100.64.0.0/10 (espace CGNAT), dérivé d’un ID site. Ils l’ont documenté comme un produit : tables de mapping, règles DNS, conventions de nommage des objets pare-feu, et un petit job CI qui validait qu’aucun deux sites n’avaient de plages traduites chevauchantes.

Puis ils ont fait la partie pas glamour : un banc de test. Quelques hôtes Linux dans chaque site exécutaient des pings programmés, des handshakes TCP et des requêtes DNS vers une liste d’IP de services traduits. Les résultats alimentaient un tableau de bord avec latence, perte de paquets et « première heure de défaillance ». Pas de magie. Juste de l’instrumentation.

Six mois plus tard, un changement d’ISP a introduit une régression MTU qui n’a cassé que SMB sur le tunnel (ICMP fonctionnait toujours, évidemment). Le banc a détecté le problème en quelques minutes. L’équipe a ajusté le MSS clamping sur le bord VPN et évité une coupure d’une journée pour les services fichiers.

Personne n’a reçu de trophée. Mais ils n’ont pas passé leur week-end en war room non plus, et c’est le meilleur prix.

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

Vous ne pouvez pas réparer ce que vous ne pouvez pas prouver. Ci-dessous des tâches réelles à exécuter depuis des hôtes Linux et systèmes réseau adjacents. Chaque tâche inclut : la commande, ce que signifie la sortie, et la décision à en tirer.

Task 1: Prove the “remote IP” is actually local (ARP check)

cr0x@server:~$ ip neigh show 10.10.1.20
10.10.1.20 dev eth0 lladdr 3c:52:82:aa:bb:cc REACHABLE

Signification : Votre hôte croit que 10.10.1.20 est sur le segment L2 local (a un MAC sur eth0). Ce ne peut pas être un hôte routé distant à travers un VPN.

Décision : Arrêtez de déboguer le tunnel. Vous avez un chevauchement (ou une mauvaise configuration proxy ARP). Planifiez NAT/VRF/overlay.

Task 2: Confirm which route wins for the overlapping destination

cr0x@server:~$ ip route get 10.10.1.20
10.10.1.20 dev eth0 src 10.10.1.100 uid 1000
    cache

Signification : Le noyau route 10.10.1.20 via eth0 localement.

Décision : Si vous attendiez le VPN, il vous faut une nouvelle frontière d’espace de noms ; vous ne pouvez pas « policy router » votre sortie si la destination existe localement.

Task 3: Traceroute to see if traffic ever hits the VPN path

cr0x@server:~$ traceroute -n 10.10.1.20
traceroute to 10.10.1.20 (10.10.1.20), 30 hops max, 60 byte packets
 1  10.10.1.1  0.412 ms  0.381 ms  0.372 ms
 2  10.10.1.20  0.663 ms  0.631 ms  0.612 ms

Signification : Deux sauts, entièrement local. Ne traverse pas un tunnel.

Décision : Ne modifiez pas encore les sélecteurs VPN. Résolvez d’abord le chevauchement.

Task 4: Verify the VPN interface exists and is up (sanity check, not victory)

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

Signification : L’interface est up. Cela ne dit rien sur le routage correct pour les destinations chevauchantes.

Décision : Passez à la vérification du routage/NAT/VRF ; ne déclarez pas la victoire.

Task 5: Check WireGuard peer health (example overlay/mesh)

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

peer: lH8k1m2n3b4v5c6x7z8a9s0d1f2g3h4j5k6l7p8o9=
  endpoint: 203.0.113.10:51820
  allowed ips: 100.64.10.0/24
  latest handshake: 32 seconds ago
  transfer: 1.24 MiB received, 2.88 MiB sent

Signification : Le pair est vivant, allowed IPs définit la plage de route overlay.

Décision : Si le chevauchement persiste, assurez-vous de router vers les IP overlay, pas vers les duplicatas de l’underlay.

Task 6: Validate DNS is pointing at translated/overlay addresses, not the conflicting underlay

cr0x@server:~$ dig +short reports.internal.example A
172.20.50.40

Signification : Le nom résout vers une adresse traduite/non chevauchante (bon signe pour une intégration basée NAT).

Décision : S’il retourne 10.50.12.40 et que cela chevauche, corrigez le DNS split-horizon ou créez des enregistrements d’intégration spécifiques.

Task 7: Verify NAT is happening (conntrack view)

cr0x@server:~$ sudo conntrack -L -p tcp --dport 443 | head
tcp      6 431999 ESTABLISHED src=10.10.1.100 dst=172.20.50.40 sport=51922 dport=443 src=10.10.1.100 dst=10.50.12.40 sport=51922 dport=443 [ASSURED] mark=0 use=1

Signification : La destination d’origine est 172.20.50.40, mais elle est DNATée en 10.50.12.40 de l’autre côté (ou inversement selon le placement). Le tuple montre la traduction.

Décision : Si aucune entrée conntrack n’apparaît pendant un test, la règle NAT ne matche pas ou le trafic n’atteint pas le traducteur.

Task 8: Confirm iptables NAT rules match what you think they match

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -i wg0 -d 172.20.50.40/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.50.12.40:443
-A POSTROUTING -o wg0 -s 10.50.12.40/32 -p tcp -m tcp --sport 443 -j SNAT --to-source 172.20.50.40

Signification : NAT déterministe bidirectionnel pour un seul service (443). DNAT entrant, SNAT sortant.

Décision : Gardez le NAT symétrique pour les protocoles à état. Si vous ne DNATez qu’un côté, le retour peut router vers le jumeau local et mourir.

Task 9: Check for MTU/MSS problems that masquerade as “overlap issues”

cr0x@server:~$ ping -M do -s 1372 172.20.50.40 -c 3
PING 172.20.50.40 (172.20.50.40) 1372(1400) bytes of data.
1372 bytes from 172.20.50.40: icmp_seq=1 ttl=61 time=18.4 ms
1372 bytes from 172.20.50.40: icmp_seq=2 ttl=61 time=18.1 ms
1372 bytes from 172.20.50.40: icmp_seq=3 ttl=61 time=18.3 ms

--- 172.20.50.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Signification : Des paquets de 1400 octets passent sans fragmentation. Bon pour de nombreux VPN/overlay.

Décision : Si ceci échoue mais que les petits pings fonctionnent, clamppez le MSS sur le bord et réglez la MTU du tunnel avant d’accuser la config NAT/VRF.

Task 10: Confirm which interface a packet leaves from (useful with policy routing/VRFs)

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.10.1.0/24 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Signification : Le routage basé source est en place pour 10.10.1.0/24 via la table 100.

Décision : Si le chevauchement vous force dans des astuces de policy routing, vérifiez que les réseaux source sont uniques. Le policy routing ne résout pas des destinations identiques sur le même segment hôte.

Task 11: Inspect the alternate routing table for the VRF/policy domain

cr0x@server:~$ ip route show table 100
default via 100.64.10.1 dev wg0
100.64.10.0/24 dev wg0 proto kernel scope link src 100.64.10.2

Signification : La table 100 envoie le trafic dans l’overlay via wg0.

Décision : Si les services doivent utiliser les IP overlay, assurez-vous que les bonnes sources atterrissent dans la bonne table ; sinon elles fuiront vers main et toucheront les jumeaux locaux.

Task 12: Detect duplicate IPs from logs (when users swear it’s “random”)

cr0x@server:~$ sudo journalctl -k | grep -i duplicate | tail -n 5
Dec 28 09:11:02 edge kernel: IPv4: martian source 10.10.1.20 from 10.10.1.1, on dev eth0
Dec 28 09:12:44 edge kernel: arp: 10.10.1.20 moved from 3c:52:82:aa:bb:cc to 00:11:22:33:44:55 on eth0

Signification : La même IP est vue avec des MACs différents. C’est soit un vrai déplacement (migration VM) soit — plus probable dans ce contexte — des IP dupliquées/chevauchement/fuite L2.

Décision : Si vous voyez des mouvements de MAC entre sites, stoppez. Vous avez peut-être accidentellement ponté du L2 sur le WAN ou étendu des VLANs. C’est une autre urgence.

Task 13: Verify firewall path selection with packet capture (prove where traffic goes)

cr0x@server:~$ sudo tcpdump -ni wg0 host 172.20.50.40 and tcp port 443 -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
09:21:11.102334 IP 10.10.1.100.51922 > 172.20.50.40.443: Flags [S], seq 39184422, win 64240, options [mss 1360,sackOK,TS val 123 ecr 0], length 0
09:21:11.120118 IP 172.20.50.40.443 > 10.10.1.100.51922: Flags [S.], seq 91233110, ack 39184423, win 65160, options [mss 1360,sackOK,TS val 456 ecr 123], length 0

Signification : SYN/SYN-ACK visibles sur l’interface de tunnel ; le trafic entre correctement dans l’overlay/VPN pour l’IP traduite.

Décision : Si vous voyez SYN partir mais pas de SYN-ACK revenir, suspectez du NAT/politique côté distant, un mauvais routage retour, ou un problème MTU. Si vous ne voyez rien sur wg0, le routage en amont est incorrect.

Task 14: Validate that “integration subnets” do not overlap with anything else

cr0x@server:~$ ipcalc 172.20.50.0/24
Address:   172.20.50.0         10101100.00010100.00110010. 00000000
Netmask:   255.255.255.0 = 24  11111111.11111111.11111111. 00000000
Network:   172.20.50.0/24      10101100.00010100.00110010. 00000000
Broadcast: 172.20.50.255       10101100.00010100.00110010. 11111111
HostMin:   172.20.50.1         10101100.00010100.00110010. 00000001
HostMax:   172.20.50.254       10101100.00010100.00110010. 11111110
Hosts/Net: 254

Signification : Vous définissez un segment de traduction/overlay propre.

Décision : Placez ces plages sous contrôle de changement. Si une autre équipe utilise plus tard 172.20.50.0/24 localement, vous réintroduirez le chevauchement — juste avec d’autres numéros.

Task 15: Quick application-level test that avoids “ping lies”

cr0x@server:~$ curl -skI https://172.20.50.40/ | head -n 5
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 28 Dec 2025 09:25:02 GMT
Content-Type: text/html
Connection: keep-alive

Signification : Le service est joignable à l’IP traduite/overlay. C’est plus significatif que l’ICMP.

Décision : Si curl fonctionne mais l’appli échoue toujours, concentrez-vous sur le DNS, les certificats, le SSO/identité, ou les politiques L7 du pare-feu — pas sur « le VPN ».

Task 16: Confirm the local network already uses your proposed translation range (the “don’t be clever” check)

cr0x@server:~$ ip route show | egrep '172\.20\.50\.0/24|100\.64\.0\.0/10' || echo "no local routes found"
no local routes found

Signification : La plage de traduction/overlay choisie n’apparaît pas localement sur cet hôte.

Décision : Répétez sur les routeurs cœur et les sources DHCP/IPAM. Si la plage est utilisée ailleurs, choisissez-en une autre maintenant, pas après le déploiement.

Erreurs courantes : symptômes → cause racine → correctif

1) « Le tunnel est up mais rien ne marche »

Symptôme : VPN connecté ; pings vers les IP « distantes » réussissent de façon incohérente ; traceroute reste local.

Cause racine : Sous-réseau chevauchant cause la route/ARP locale à gagner ; vous atteignez des jumeaux locaux.

Fix : Introduire un espace de noms non chevauchant (NAT/overlay) et utiliser le DNS pour diriger les clients vers des adresses traduites.

2) « Certaines applis fonctionnent, SMB/VoIP non »

Symptôme : Applications web OK ; partages fichiers bloquent ; transferts volumineux suspendus ; audio VoIP unidirectionnel.

Cause racine : Problèmes MTU/MSS dus à l’encapsulation VPN, souvent révélés après ajout d’overlays.

Fix : Définir la MTU du tunnel adéquatement et clamp le MSS TCP sur les bords ; vérifier avec pings sans fragmentation et tests applicatifs réels.

3) « On a fait du NAT et maintenant l’équipe distante ne peut pas nous whitelist »

Symptôme : Politiques de sécurité distantes rejettent le trafic ; les logs montrent des sources inattendues.

Cause racine : Le SNAT change l’identité du client ; les listes blanches distantes étaient construites pour les plages originales.

Fix : Utiliser des plages NAT déterministes par site, les documenter et fournir un CIDR source stable pour les whitelistes.

4) « Le DNS est correct mais les utilisateurs touchent quand même le mauvais système »

Symptôme : Le nom résout en IP traduite/overlay ; pourtant les connexions aboutissent à un hôte inattendu.

Cause racine : Mismatch DNS split-horizon, caches obsolètes, ou entrées hosts locales ; parfois un proxy auto-config contourne votre plan.

Fix : Videz les caches quand il faut, auditez le DNS fourni par DHCP, retirez les overrides hosts, et validez depuis les sous-réseaux clients avec dig/nslookup.

5) « Le déploiement VRF a cassé la supervision et les logs »

Symptôme : NMS ne peut plus joindre des équipements ; syslog s’arrête ; NetFlow manquant pour un segment.

Cause racine : Le trafic des outils vit dans la mauvaise VRF, ou les collecteurs ne sont pas atteignables via la fuite de routes.

Fix : Planifier explicitement le routage du plan de gestion : soit fuir les routes pour les services de management, soit exécuter des collecteurs par VRF/segment.

6) « On a résumé les routes pour simplifier, puis des accès bizarres sont apparus »

Symptôme : Des utilisateurs atteignent des interfaces admin d’autres agences ; segmentation violée.

Cause racine : Résumés de routes et politiques trop larges sur des plages chevauchantes ont supprimé la spécificité nécessaire.

Fix : Réintroduire la spécificité : traduction par site, objets de pare-feu par sous-réseau traduit, et politiques least-privilege basées sur les identités traduites/overlay.

7) « Les paquets arrivent mais les réponses se perdent »

Symptôme : SYN vu partir ; pas de SYN-ACK ; ou la requête atteint le distant mais la réponse retourne au réseau jumeau local.

Cause racine : Routage asymétrique dû à du NAT unidirectionnel, routes de retour manquantes, ou le côté distant préfère sa route locale chevauchante.

Fix : Assurez un NAT symétrique (DNAT+SNAT) ou imposez le routage de retour via le même tunnel (sélecteurs VPN basés sur politique ou VPN route-based avec routes correctes).

Checklists / plan pas à pas

Checklist A: Choisir la solution en 30 minutes

1. Lister les flux inter-sites requis (sous-réseau source → service destination → ports → bidirectionnel ?).
2. Confirmer l’étendue du chevauchement : préfixes exacts qui se heurtent (10.10.0.0/16 vs 10.10.0.0/16, etc.).
3. Identifier les points de contrôle : gérez-vous les deux bords ? Pouvez-vous changer le DNS ? Pouvez-vous ajouter des passerelles ?
4. Choisir le plus petit marteau :
   • Besoin d’accès à des services spécifiques rapidement → NAT
   • Besoin d’isolation et de services partagés sans fusion complète → VRFs
   • Besoin d’un fabric multi-site évolutif ou d’intégration cloud → overlay
5. Choisir une plage d’intégration non chevauchante et la réserver (ne pas « emprunter » un /24 au hasard).

Checklist B: Plan de déploiement NAT sans scène de crime

1. Concevoir des mappages déterministes (blocs traduits par site ; éviter les one-off).
2. Décider la directionnalité :
   • Utilisateurs → serveurs seulement : le SNAT peut suffire.
   • Services bidirectionnels : utiliser du NAT statique symétrique.
3. Mettre à jour le DNS pour que les clients utilisent les IP traduites pour les noms inter-sites.
4. Mettre à jour les politiques pare-feu pour ne permettre que les plages traduites (least privilege, pas « any any »).
5. Valider MTU/MSS sur le chemin du tunnel pour les plus gros paquets attendus.
6. Instrumenter : captures sur l’interface VPN ; probes TCP de base ; logs des hits NAT.
7. Documenter les mappages dans un emplacement autoritaire et soumettre les changements à revue.
8. Plan de rollback : un bascule/commit unique sur l’équipement de bord, plus gestion du TTL DNS.

Checklist C: Plan de déploiement VRF pour confinement et services partagés

1. Définir les frontières VRF : quels VLANs/sous-réseaux appartiennent à quelle VRF (local vs acquis/distant).
2. Attacher le WAN/VPN à la VRF pour le domaine de routage du site distant.
3. Planifier l’accès aux « services partagés » (DNS, AD, logging, patching) via fuite de routes contrôlée ou proxys.
4. Mettre à jour les politiques de sécurité pour qu’elles soient VRF-aware ; vérifier l’accès management-plane.
5. Tester en labo ou sur un site pilote avec des applis représentatives (SMB, Kerberos, VoIP si pertinent).
6. Opérationnaliser : checks de monitoring par VRF, runbooks, et procédures de capture de paquets.

Checklist D: Plan de déploiement Overlay quand vous en avez fini avec les exceptions

1. Choisir le schéma d’identité overlay (par-site /24, par-service /32, ou assignations par hôte).
2. Décider la stratégie d’endpoint :
   • Doublement des interfaces des serveurs critiques dans l’overlay (plus rapide pour un scope limité).
   • Déployer des passerelles par site (moins de changements d’endpoints).
3. Valider la MTU bout en bout et configurer le MSS clamping si nécessaire.
4. Définir le routage : quels préfixes sont annoncés où ; éviter d’annoncer les chevauchements underlay dans l’overlay.
5. Sécurité : traitez l’overlay comme un réseau de production — journalisation, ACL, rotation des clés, segmentation.
6. Migration : déplacez un service à la fois ; mettez à jour le DNS ; mesurez ; puis continuez.

Une citation fiabilité pour rester honnête

L’espoir n’est pas une stratégie. — General Gordon R. Sullivan

Faits et contexte historique (bon à savoir)

• RFC1918 (1996) a créé des plages d’adresses privées explicitement pour réduire la consommation IPv4 — le chevauchement était un effet secondaire accepté, pas un bug.
• Le NAT a explosé dans les années 1990 comme réponse pratique à la rareté IPv4 ; il a aussi normalisé l’idée que « les adresses peuvent être réécrites » en transit.
• CGNAT (Carrier-Grade NAT) a popularisé l’usage de 100.64.0.0/10 comme espace partagé ; les entreprises l’empruntent désormais en interne pour la translation car il est moins susceptible de coller avec les routeurs domestiques.
• Les concepts VRF ont mûri avec les VPN MPLS ; le même mécanisme qui isole les clients pour les opérateurs isole les locataires chevauchants en entreprise.
• Les VPN basés route (interfaces + routage) sont devenus dominants par rapport aux VPN basés politique car ils montent mieux, mais le chevauchement nécessite toujours une correction d’espace de noms.
• Les overlays EVPN/VXLAN ont émergé pour résoudre les problèmes d’échelle multi-tenant des datacenters ; ces mêmes patterns apparaissent maintenant en campus et branches.
• Le DNS split-horizon est une astuce d’entreprise depuis des décennies, mais il devient non optionnel quand les adresses traduites/overlay diffèrent selon le site.
• Les grandes entreprises exécutent routinièrement plusieurs « réalités IP » pendant les fusions : espace d’adresses d’origine, espace d’intégration traduit, et espace futur renuméroté — souvent simultanément.

FAQ

1) Puis-je corriger des sous-réseaux chevauchants en changeant les métriques de route ou en ajoutant des routes statiques ?

Pas de manière fiable. Si un sous-réseau existe localement, vos hôtes et routeurs préféreront la route connectée. Vous avez besoin d’une frontière d’espace de noms : NAT, séparation VRF, ou adressage overlay.

2) Le NAT est-il toujours le correctif le plus rapide ?

Généralement, oui — surtout pour un jeu limité de services. Mais « rapide » n’est pas « gratuit ». Le NAT ajoute de l’état de traduction, complexifie les politiques et rend le dépannage plus subtil. Si vous prévoyez une intégration profonde (AD, beaucoup d’est-ouest), considérez la planification VRF/overlay tôt.

3) Quelle plage de translation devrais-je utiliser ?

Choisissez une plage peu susceptible d’exister dans l’une ou l’autre entreprise et réservez-la centralement. Beaucoup d’équipes utilisent 100.64.0.0/10 pour la translation/overlay car elle est moins couramment utilisée sur les LAN que 10/8. L’important est la gouvernance : réservez-la, documentez-la et tenez-la hors des scopes DHCP.

4) Ai-je besoin d’un NAT bidirectionnel ?

Si les deux côtés initient des connexions vers le même service, oui — planifiez DNAT/SNAT symétriques pour que les chemins de retour restent cohérents. Pour l’accès unidirectionnel « clients vers serveurs », le SNAT seul peut fonctionner, mais vous devez toujours garantir que les réponses reviennent via le traducteur.

5) Les VRF peuvent-elles résoudre le chevauchement sans NAT ?

Les VRF empêchent les collisions en isolant les domaines de routage, mais elles ne permettent pas à deux adresses identiques de se parler directement. Si VRF-A doit atteindre un hôte en VRF-B qui partage la même IP qu’un hôte en VRF-A, il vous faudra toujours de la traduction ou un proxy.

6) Quel est le plus grand risque avec les overlays ?

La MTU et la complexité opérationnelle. L’encapsulation réduit la MTU effective ; si le PMTUD casse, les applications échouent de façon étrange. De plus, les overlays ajoutent un plan de contrôle qu’il faut surveiller et comprendre.

7) Comment garder le DNS cohérent pendant tout ça ?

Décidez quels noms doivent résoudre en IP traduite/overlay et imposez-le avec un DNS split-horizon. Maintenez des TTL courts pendant la migration. Et auditez les IP en dur — il y en aura.

8) Et si seulement une poignée d’utilisateurs doit accéder entre sites ?

Utilisez un jump host ou un proxy applicatif dans un segment neutre non chevauchant (ou overlay). Cela limite le rayon d’action et réduit le nombre de flux traduits. N’ouvrez pas tout l’espace d’adresses « parce que c’est plus simple ».

9) Cela affectera-t-il les sauvegardes et la réplication ?

Oui, et parfois de manière surprenante. Les outils de réplication peuvent se baser sur des IPs, imposer des listes d’autorisation source, ou mal fonctionner sous NAT si ils embarquent des adresses. Testez avec des transferts réels et mesurez débit et taux d’erreur avant de déclarer victoire.

10) Devons-nous quand même prévoir une renumérotation éventuellement ?

Oui, si vous voulez une vie à long terme plus simple. Ces solutions sont valides, mais elles ajoutent des couches. La renumérotation est douloureuse ; vivre avec un chevauchement permanent et des NAT ad-hoc est pire.

Conclusion : prochaines étapes exécutables

Les sous-réseaux chevauchants ne sont pas rares ; ils sont le résultat par défaut d’une IT décentralisée plus RFC1918 plus le temps. Ce qui compte, c’est la manière dont vous réagissez. Si vous faites semblant que c’est « juste un problème de routage », vous gaspillerez des jours à prouver la même défaillance de différentes manières.

Faites ceci ensuite :

1. Exécutez le diagnostic rapide : ARP/route/traceroute pour prouver le chevauchement et identifier les flux importants.
2. Choisissez une solution volontairement :
   • NAT pour un accès rapide et centré services.
   • VRFs pour confinement et services partagés contrôlés.
   • Overlay pour intégration évolutive et future-proof.
3. Réservez un espace d’adressage d’intégration (traduit/overlay), documentez-le et protégez-le contre la réutilisation accidentelle.
4. Instrumentez dès le premier jour : pas seulement « tunnel up », mais probes applicatives, checks MTU et captures reproductibles.
5. Rédigez le runbook tant que la douleur est fraîche. Le vous du futur sera fatigué et peu amusé.

Si vous devez choisir une approche pour la plupart des fusions réelles : commencez par du NAT déterministe pour les services critiques, puis passez à VRF/overlay à mesure que vous comprenez ce que « l’intégration » signifie réellement dans votre environnement.