Deux sites, un même sous-réseau : créez une vue d’alias pour chacun

Deux sites clients exploitent tous deux 192.168.50.0/24, et un ingénieur distant doit atteindre une imprimante à la même adresse sur chacun. Aucune astuce de routage ne résout cette ambiguïté à elle seule. Chaque site a besoin d’une vue d’adresses distincte, et la passerelle doit choisir le site à partir de cette vue avant de transmettre quoi que ce soit.

Le plan comporte quatre parties : les préfixes d’alias, les deux sens de traduction, la politique de superposition et les noms. Chacune doit s’accorder avec les autres.

Choisissez un préfixe d’alias par site

Attribuez à chaque site un préfixe d’alias complet qui n’appartient à personne d’autre dans l’environnement. Un plan à deux sites peut mapper 192.168.50.0/24 du site A vers 172.21.10.0/24 et le LAN identique du site B vers 172.21.20.0/24. Vérifiez les candidats contre chaque réseau participant, y compris les VPC cloud et les autres pools VPN. L’espace d’adressage privé est partagé par toute organisation, donc le fait qu’une plage soit RFC 1918 ne dit rien sur sa disponibilité ici.

Publiez l’alias, pas le sous-réseau natif, auprès des utilisateurs distants. La plage native reste un fait local.

Traduisez dans les deux sens

Traduisez dans les deux sens. Le mappage de destination réécrit une adresse d’alias en adresse native sur le site propriétaire. Le mappage de source réécrit l’appelant distant en un alias que les autres sites peuvent distinguer.

Un mappage statique un-à-un est déterministe, et cela ne rend pas l’implémentation sans état. La traduction inverse peut dépendre de l’état de la connexion, et le basculement ou les chemins asymétriques peuvent casser un plan qui l’ignore. La documentation de la plateforme décide lequel de ces cas s’applique.

L’étape exacte où s’appliquent la politique, les sélecteurs et les routes diffère entre l’IPsec basé sur des politiques, les tunnels basés sur des routes et d’autres produits. Concevez pour celui que vous exploitez.

Portez le plan à travers la superposition

Dans un hub, attribuez chaque préfixe d’alias au chemin du site qui le possède et n’autorisez que le transit dont la tâche a besoin. Dans un maillage, chaque pair concerné a besoin du même préfixe et de la même connaissance de la politique. L’ajout de tunnels ne corrige pas l’adressage ambigu à lui seul.

La publication de tout le sous-réseau est plus large que celle d’un seul service. Si seules quelques machines ou ports sont nécessaires, gardez les règles d’accès plus étroites que le mappage.

La traduction d’en-tête ne réécrit pas les charges utiles de l’application. Les redirections, les adresses intégrées aux fichiers de configuration et les permissions basées sur la source peuvent encore porter l’adresse native. Testez le chemin de l’application, pas seulement le ping. Une réponse ICMP qui fonctionne prouve que le mappage existe et ne dit rien sur la question de savoir si l’application accepte l’alias.

Corrigez les noms que chaque appelant voit

Donnez aux noms de maintenance des réponses qui correspondent à la vue de l’appelant. Si l’ingénieur distant résout un nom d’hôte, il devrait renvoyer l’adresse d’alias de ce site, pas la plage native partagée.

Vérifiez les vues DNS par site avant la première fenêtre de maintenance. Un nom qui résout vers le sous-réseau natif renvoie l’appelant dans l’ambiguïté que le plan devait supprimer.

Enregistrez et vérifiez par site

Acceptez chaque site séparément depuis un appelant réel et confirmez quelle machine a répondu. Enregistrez ensemble l’adresse native, l’alias, la passerelle propriétaire et le service autorisé.

C’est cet inventaire qui préserve la distinction lorsqu’un troisième site arrive avec le même LAN par défaut. Le guide NAT IPsec basé sur des politiques documente un modèle de traduction concret ; ce n’est pas un contrat pour toutes les plateformes.