Anypoint VPN o NAT de Transit Gateway: on es tradueix

Un requisit de NAT no és un requisit fins que anomena les adreces que canvien i el component a qui es permet canviar-les. A la connectivitat de MuleSoft aquesta decisió té tres entrades: si el backend necessita traducció de ports de molts a un o un àlies de prefix d'un a un, si l'enllaç d'AWS que realment teniu pot fer aquest mapatge, i si tot el camí es queda dins d'una combinació que el proveïdor admet. Si us equivoqueu, construïu un laboratori que funciona però no passa la revisió.

El punt fix és que Anypoint VPN no és cap dispositiu de traducció. La documentació de CloudHub 2.0 hi llista NAT com a no suportat, així que qualsevol disseny que assumeixi que el túnel amagarà les adreces dels vostres treballadors ja està trencat.

Decidiu què ha de fer la traducció

Si molts treballadors d'aplicació han d'aparèixer al backend com una sola adreça, el requisit és una traducció d'origen compartida, normalment SNAT o PAT amb estat en un tallafoc que controleu. Aquest element ha d'estar en un camí aprovat, mantenir el seu estat durant tota la vida del flux i veure el trànsit de tornada de cada connexió que ha reescrit. Perdre l'estat a mig camí no degrada la connexió; l'acaba. Una parella de tallafocs que es negui a compartir l'estat de traducció deixarà caure cada sessió que caigui al membre d'espera després del basculament. Dimensioneu aquest element per a fluxos concurrents, no per a rendiment.

Si, en canvi, dues xarxes se superposen i cada host necessita un àlies distint, el requisit és un pla d'adreces d'un a un amb prefixos mapats inequívocs, rutes coincidents i resolució de noms que coincideixi amb el mapatge. Amagar cada treballador darrere d'una adreça no és una versió més barata d'això, i intercanviar l'un per l'altre en una revisió de disseny és com els projectes perden un trimestre.

Enregistreu la decisió en termes concrets abans de triar un producte: origen original, destí original, valor traduït, direcció d'inici, propietari del traductor i ruta de resposta esperada. Afegiu quina identitat conservaran els registres del backend, perquè un disseny que amaga tots els orígens també destrueix l'auditoria per client.

Comproveu si AWS pot fer el mapatge per vosaltres

AWS ja documenta NAT gestionat d'un a un en enllaços de Transit Gateway i Cloud WAN, anunciat a finals d'octubre de 2026, així que l'antiga afirmació general que una passarel·la de trànsit mai pot traduir ja és obsoleta. La documentació de Transit Gateway NAT descriu un mapatge de prefixos IPv4 sense estat: els prefixos originals i traduïts mantenen la mateixa longitud, i els bits d'amfitrió i els ports de transport sobreviuen a la traducció. Llegiu les direccions d'entrada i de sortida com a decisions de disseny separades, perquè es configuren per separat i una pot estar a punt mentre l'altra no. Res d'aquesta descripció no implica estat per flux, així que no espereu que el mapatge segueixi les connexions per vosaltres.

Això vol dir que 10.80.0.0/16 mapat a 172.28.0.0/16 converteix 10.80.10.23 en 172.28.10.23. No col·lapsa el /16 en una adreça i no substitueix un requisit de PAT. També cobreix tipus d'enllaç seleccionats, entre ells VPC i Site-to-Site VPN, però no enllaços de Client VPN, i la configuració viu amb el propietari de la passarel·la de trànsit, no amb la part d'Anypoint.

Tracteu la funció com un punt de control més possible, no com a prova que el vostre desplegament la pugui fer servir. CloudHub 2.0 documenta enllaços d'espai privat a una passarel·la de trànsit al compte d'AWS propi del client, amb condicions regionals i de dret, així que confirmeu el tipus real d'enllaç, el seu propietari i la posició de suport del proveïdor abans de dissenyar al voltant de la nova opció.

Manteniu el camí dins d'una frontera suportada

Per a un traductor de tallafoc, feu servir el model de VPN, traducció i encaminament suportat d'aquest producte en lloc d'enganxar una regla NAT genèrica en un túnel que funciona. La resposta del backend ha de tornar pel mateix element de traducció, i un túnel de sortida sa no diu res d'aquest camí de tornada.

Per a la ruta de la passarel·la de trànsit, inventarieu l'enllaç d'espai privat, les taules de rutes rellevants, l'enllaç local i les peces que el client pot configurar realment. És una arquitectura de connectivitat diferent, no una casella de NAT cargolada a una connexió Anypoint VPN existent, i la frontera de suport es mou amb ella.

Compareu les tres opcions en una taula

La majoria d'equips només han de respondre dues preguntes: molts a un o un a un, i qui posseeix l'enllaç. La taula següent converteix aquestes respostes en una opció inicial.

Llegiu la tercera columna com la pregunta de revisió, no com una idea posterior. Un mapa de prefixos permès sobre el paper però configurat en un enllaç que no posseïu segueix sent un projecte bloquejat, i una regla PAT que deixa passar el trànsit però trenca el registre per client falla l'auditoria que ve després.

Valideu el mapatge abans de prometre'l

Envieu una operació nova d'aplicació pel camí i confirmeu la resposta, no només la petició. Pregunteu al propietari del backend quina adreça d'origen han enregistrat els seus registres, comproveu que el tractament de la família d'adreces coincideix amb el pla en totes dues direccions i verifiqueu que un camí que hauria de ser denegat encara ho és. Una connexió antiga no demostra res sobre el mapatge que acabeu de canviar.

Manteniu l'autenticació del backend independent de quina adreça traduïda satisfaci la seva llista permesa, perquè el mapatge és fontaneria de xarxa i no una decisió de control d'accés. En el moment que un restabliment de contrasenya depèn d'un prefix NAT, cada canvi futur de rang es converteix en una caiguda.

Abans de l'aprovació, escriviu les tres respostes: tipus de traducció, propietari del traductor i l'enllaç o camí de producte suportat que el porta. Si qualsevol d'elles encara és una suposició, el disseny no està a punt per a una finestra de canvis.