Quand le NAT à l’intérieur d’un VPN site à site mérite sa place

Deux sites utilisent tous deux la même plage privée, et le tunnel monte alors que rien d’utile ne le traverse. La traduction est la réponse habituelle, et c’en est une vraie : présenter une autre plage au côté distant peut résoudre un chevauchement ou un chemin de retour que l’autre réseau ne sait pas router. La partie qu’on omet, c’est que la traduction change les adresses que voit chaque décision ultérieure. Traitez-la comme une décision de conception documentée avec un mappage écrit, et non comme une règle ajoutée jusqu’à ce qu’un ping réussisse.

Décidez quelle adresse est réécrite

La traduction de source change ce que le service distant et ses journaux voient comme client, si bien qu’un hôte de succursale devient une adresse de passerelle à l’arrivée. La traduction de destination ou de préfixe présente au contraire une adresse alternative pour une ressource distante. Certains déploiements ont besoin d’une traduction coordonnée des deux côtés pour séparer deux réseaux par ailleurs identiques, et c’est dans la combinaison que commence l’essentiel de la confusion.

Notez la source avant traduction, la destination telle que l’application la nomme, et la paire d’adresses sur laquelle chaque passerelle s’accorde. Trois colonnes suffisent, et la troisième colonne est celle que les gens oublient.

L’ordre des sélecteurs compte aussi. La sélection et la traduction de politique IPsec se font à des étapes définies, donc un sélecteur écrit pour les adresses d’avant traduction peut ne jamais correspondre au paquet à l’étape que vous supposiez. Vérifiez la politique installée plutôt que celle que vous comptiez installer, car les deux divergent exactement quand une règle est acceptée par un composant et ignorée par un autre :

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

Suivez la charge utile et le chemin de retour

Un serveur qui journalise la source traduite au lieu de l’hôte de succursale individuel cassera toute règle ou tout rapport lié à l’adresse d’origine. Avant de changer le mappage, déterminez si quelque chose en aval décide à partir de ce champ : listes d’accès, rapports d’audit, limites de débit, contrôles de licence. Chacun de ces points est un endroit où la traduction réapparaît plus tard comme une panne inexpliquée.

Les protocoles qui transportent des adresses dans leur charge utile demandent une planification séparée, car réécrire l’en-tête externe ne touche pas la référence interne. FTP actif, SIP et certains produits d’accès distant sont les cas classiques, et une conception qui les ignore fonctionnera pour le trafic web et échouera pour l’application qui comptait.

Le trafic de retour dépend de mappages à état. Le basculement de passerelle peut perdre cet état, le routage asymétrique peut le contourner, et un redémarrage peut l’effacer alors que des sessions restent ouvertes côté distant. C’est pourquoi une requête qui atteint la destination et une session qui se termine sont deux résultats d’acceptation différents.

Pesez-le face à la renumérotation d’un site

Renuméroter un site en conflit supprime entièrement le mappage et laisse un plan d’adressage lisible sans tables de traduction. C’est coûteux sur le plan opérationnel : les enregistrements DNS, les affectations statiques, les règles de pare-feu et chaque adresse documentée doivent changer ensemble. Le coût tombe une fois, dans une fenêtre planifiée, avec un état final clair. Ce que vous achetez, c’est la capacité de lire une capture de paquets des années plus tard sans table de correspondance.

La traduction évite la plupart des changements locaux et crée un mappage qu’il faut maintenir dans le DNS, la documentation et le dépannage pour toujours. Le coût tombe en continu, sous la forme de chaque futur ingénieur qui doit apprendre qu’un préfixe signifie autre chose à l’intérieur du tunnel.

Pour une connexion temporaire ou un réseau partenaire que vous ne contrôlez pas, le coût continu vaut généralement la peine. Pour deux sites que vous possédez et posséderez pendant des années, la renumérotation est souvent la décision la moins chère une fois la migration comptée honnêtement.

Prouvez les deux sens avec une vraie session

Testez une session applicative plutôt qu’une sonde unique. Une requête d’écho réussie prouve qu’un sens d’un protocole fonctionne, et elle est parfaitement compatible avec un chemin de retour qui échoue pour tout ce qui est à état. Utilisez le service qui a motivé la conception et lisez son journal à l’extrémité distante pour voir quelle adresse source il a enregistrée.

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

Confirmez ensuite que seuls les services prévus sont joignables à travers le mappage. La traduction change l’adressage et ne fait rien pour l’autorisation, donc la politique du pare-feu décide toujours de ce qui est permis. Une conception qui s’appuie sur un préfixe traduit obscur comme contrôle d’accès n’a aucun contrôle d’accès du tout.

Consignez le mappage, la session testée et les adresses observées de chaque côté. La prochaine personne qui débogue ce tunnel a plus besoin de ces trois faits que du fichier de configuration.