Le NAT d'Azure VPN ne règle pas les adresses VNet qui se chevauchent
Deux VNet avec la même plage privée ne se connecteront pas simplement parce que NAT existe. Vérifiez d'abord le type de connexion, puis renumérotez ou possédez un alias de traduction.
Les deux VNet utilisent 10.40.1.0/24, les tunnels montent et rien ne fonctionne. Ajouter une seconde passerelle VPN n'y change rien, pas plus qu'une métrique de route plus basse, car le problème n'est pas la sélection de chemin. Deux charges de travail qui répondent à la même adresse privée laissent chaque paquet avec une destination ambiguë et un chemin de retour invérifiable. Avant de planifier une quelconque traduction, découvrez quel type de connexion vous avez réellement créé, car ce seul choix détermine si la fonction NAT d'Azure est disponible ou non.
Ce que le symptôme vous dit vraiment
Quand un hôte du VNet A envoie vers 10.40.1.10, la table de routage ne peut que le diriger quelque part. Si le VNet B contient aussi 10.40.1.10, cette adresse n'est pas une destination que le chemin peut distinguer ; c'est une adresse avec deux propriétaires.
La seconde passerelle que l'on déploie habituellement n'aide pas. Elle donne un autre tunnel, pas une autre adresse, et la plage dupliquée voyage inchangée à l'intérieur du tunnel. Elle double aussi la configuration que vous devez maintenir cohérente. Ce qu'elle ne peut pas faire, c'est faire signifier deux hôtes à une adresse.
Changer les adresses publiques des pairs VPN ne fait rien non plus. Ces adresses identifient les extrémités du tunnel, tandis que la collision se trouve dans la plage privée transportée à l'intérieur.
Le type de connexion décide si NAT est disponible
Azure VPN Gateway possède bien une capacité NAT, et elle est documentée pour les connexions IPsec intersites basées sur des routes sur certaines références SKU de passerelle. La même documentation exclut les connexions VNet-to-VNet et point à site, donc la fonction n'est pas une case à cocher qui apparaît sur chaque relation de passerelle.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Le VNet-to-VNet natif exige aussi que les plages du VNet et du réseau local ne se chevauchent pas dès le départ, ce qui est cohérent avec cette exclusion. Le peering VNet n'est pas une solution au chevauchement pour la même raison.
Il existe une alternative prise en charge que l'on confond avec le type natif : modéliser l'autre VNet comme un réseau local et le connecter comme un lien de site à site. C'est une autre ressource et une autre conception, donc traitez une connexion renommée comme un changement à valider, pas comme un simple renommage.
Renumérotez, ou traduisez avec quelque chose qui possède l'alias
Si les deux VNet sont à vous, comparez une renumérotation planifiée au coût continu de la traduction. La renumérotation touche la configuration des applications, les enregistrements DNS, les règles de sécurité et chaque connexion existante, mais elle laisse un réseau qui se lit normalement ensuite. Faites-le un sous-réseau à la fois, avec la modification DNS en dernier. Une plage à moitié renumérotée est pire que l'une ou l'autre option, car les deux préfixes paraissent alors légitimes à qui lit la table ensuite.
Là où la renumérotation n'est pas pratique, utilisez une conception traduite avec un véritable propriétaire pour l'alias. Les appelants du VNet A peuvent joindre 10.40.1.10 du VNet B en tant que 10.140.1.10, mais cet alias exige un dispositif qui traduit, une route vers lui et un comportement correspondant pour la réponse. Une adresse ajoutée au seul DNS n'est pas une traduction.
Consignez les deux plages dans les deux sens : ce que compose l'appelant, ce que la destination voit comme source, et quel côté peut prendre l'initiative. Les règles NAT d'Azure incluent la traduction inverse pour leurs mappages SNAT, vous n'écrivez donc pas à la main une règle DNAT correspondante, mais cette commodité s'arrête aux types de connexion que la fonction prend en charge.
Ce qui ne marchera pas
Une route définie par l'utilisateur ou une métrique de route ne peuvent pas créer une distinction d'adresses manquante. Les deux agissent sur une destination encore ambiguë, et le paquet arrive au prochain saut que la table préfère.
Ajouter la plage dupliquée à une table de routes comme préfixe plus spécifique ne déplace l'ambiguïté que d'un cran. Cela tend aussi à casser l'autre sens, où la réponse a désormais deux sources plausibles.
Acceptez la conception avec du trafic dans les deux sens
Prouvez la conception par une opération autorisée nouvelle de chaque côté, pas par l'état du tunnel. Un tunnel IPsec connecté dit que les pairs s'accordent sur la cryptographie ; il ne dit rien sur le fait que les destinations soient devenues distinguables.
Exécutez ensuite les chemins refusés : une adresse qui doit rester injoignable et un service que la politique doit bloquer. Si les deux réussissent encore, la traduction est plus large que ce que la conception prévoyait.
Terminez par les faits qui expliqueront l'installation plus tard : la plage d'origine, la plage présentée, le dispositif qui traduit et le sens dans lequel chaque côté peut prendre l'initiative. S'il en manque un, l'ingénieur suivant hérite d'un réseau où deux hôtes partagent un nom et où personne ne se souvient pourquoi l'un d'eux répond.