Anypoint VPN ou NAT sur Transit Gateway : où se fait la traduction
Anypoint VPN ne traduit pas les adresses lui-même. Choisissez entre un design PAT sur le pare-feu, une carte de préfixes AWS ou un autre attachement avant de promettre du NAT.
Une exigence NAT n'en est une que lorsqu'elle nomme les adresses qui changent et le composant autorisé à les changer. Sur la connectivité MuleSoft, cette décision a trois entrées : le backend a-t-il besoin d'une traduction de ports plusieurs-vers-un ou d'un alias de préfixe un-vers-un, l'attachement AWS que vous possédez réellement peut-il effectuer ce mappage, et le chemin complet reste-t-il dans une combinaison prise en charge par le fournisseur. Trompez-vous et vous construisez un lab qui fonctionne mais échoue en revue.
Le seul point fixe est qu'Anypoint VPN n'est pas lui-même un dispositif de traduction. La documentation CloudHub 2.0 y liste NAT comme non pris en charge, donc tout design qui suppose que le tunnel masquera les adresses de vos workers est déjà cassé.
Déterminez ce que la traduction doit faire
Si de nombreux workers applicatifs doivent apparaître au backend comme une seule adresse, l'exigence est une traduction de source partagée, généralement du SNAT ou du PAT avec état sur un pare-feu que vous contrôlez. Cet élément doit se trouver sur un chemin approuvé, conserver son état pendant toute la durée du flux et voir le trafic de retour de chaque connexion qu'il a réécrite. Perdre l'état en cours de session ne dégrade pas la connexion ; cela la termine. Une paire de pare-feux qui refuse de partager l'état de traduction supprimera chaque session qui atterrit sur le membre de secours après un basculement. Dimensionnez cet élément pour les flux simultanés, pas pour le débit.
Si au contraire deux réseaux se chevauchent et que chaque hôte a besoin d'un alias distinct, l'exigence est un plan d'adressage un-vers-un avec des préfixes mappés sans ambiguïté, des routes correspondantes et une résolution de noms cohérente avec le mappage. Masquer chaque worker derrière une adresse n'en est pas une version moins chère, et échanger l'un contre l'autre en revue de design, c'est ainsi que les projets perdent un trimestre.
Consignez la décision en termes concrets avant de choisir un produit : source d'origine, destination d'origine, valeur traduite, sens d'initiation, propriétaire du traducteur et route de réponse attendue. Ajoutez quelle identité les journaux du backend conserveront, car un design qui masque toutes les sources détruit aussi l'audit par client.
Vérifiez si AWS peut faire le mappage pour vous
AWS documente désormais du NAT géré un-vers-un sur les attachements Transit Gateway et Cloud WAN, annoncé fin octobre 2026, donc l'ancienne affirmation générale selon laquelle une passerelle de transit ne peut jamais traduire est dépassée. La documentation Transit Gateway NAT décrit un mappage de préfixes IPv4 sans état : les préfixes d'origine et traduits gardent la même longueur, et les bits d'hôte et les ports de transport survivent à la traduction. Lisez les sens entrant et sortant comme des décisions de design distinctes, car ils se configurent séparément et l'un peut être prêt alors que l'autre non. Rien dans cette description n'implique un état par flux, donc n'attendez pas du mappage qu'il suive les connexions à votre place.
Cela signifie que 10.80.0.0/16 mappé vers 172.28.0.0/16 transforme 10.80.10.23 en 172.28.10.23. Il ne réduit pas le /16 à une seule adresse et ne remplace pas une exigence de PAT. Il couvre aussi certains types d'attachement, dont VPC et Site-to-Site VPN, mais pas les attachements Client VPN, et la configuration réside chez le propriétaire de la passerelle de transit, pas du côté Anypoint.
Traitez la fonctionnalité comme un point de contrôle possible de plus, pas comme la preuve que votre déploiement peut l'utiliser. CloudHub 2.0 documente des attachements d'espace privé vers une passerelle de transit dans le compte AWS du client lui-même, avec des conditions régionales et d'habilitation, donc confirmez le type réel d'attachement, son propriétaire et la position de support du fournisseur avant de concevoir autour de la nouvelle option.
Gardez le chemin dans une limite prise en charge
Pour un traducteur sur pare-feu, utilisez le modèle VPN, traduction et routage pris en charge de ce produit au lieu de coller une règle NAT générique dans un tunnel qui fonctionne. La réponse du backend doit revenir par le même élément de traduction, et un tunnel sortant sain ne dit rien de ce chemin de retour.
Pour la route via la passerelle de transit, inventoriez l'attachement d'espace privé, les tables de routage concernées, l'attachement sur site et les pièces que le client peut réellement configurer. C'est une autre architecture de connectivité, pas une case NAT boulonnée sur une connexion Anypoint VPN existante, et la limite de support se déplace avec elle.
Comparez les trois options dans un seul tableau
La plupart des équipes n'ont besoin de répondre qu'à deux questions : plusieurs-vers-un ou un-vers-un, et qui possède l'attachement. Le tableau ci-dessous transforme ces réponses en option de départ.
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
Lisez la troisième colonne comme la question de revue, pas comme une réflexion après coup. Une carte de préfixes autorisée sur le papier mais configurée sur un attachement que vous ne possédez pas reste un projet bloqué, et une règle PAT qui laisse passer le trafic mais casse la journalisation par client échoue à l'audit qui suit.
Validez le mappage avant de le promettre
Faites passer une opération applicative fraîche par le chemin et confirmez la réponse, pas seulement la requête. Demandez au propriétaire du backend quelle adresse source ses journaux ont enregistrée, vérifiez que le traitement de la famille d'adresses correspond au plan dans les deux sens, et vérifiez qu'un chemin qui devrait être refusé l'est toujours. Une connexion ancienne ne prouve rien sur le mappage que vous venez de modifier.
Gardez l'authentification du backend indépendante de l'adresse traduite qui satisfait sa liste d'autorisation, car le mappage est de la plomberie réseau et non une décision de contrôle d'accès. Dès qu'une réinitialisation de mot de passe dépend d'un préfixe NAT, tout futur changement de plage devient une panne.
Avant la validation, écrivez les trois réponses : type de traduction, propriétaire du traducteur et attachement ou chemin produit pris en charge qui le porte. Si l'une d'elles est encore une supposition, le design n'est pas prêt pour une fenêtre de changement.