Anypoint VPN ou NAT de Transit Gateway: onde se traduce

Un requisito de NAT non é un requisito ata que nomea os enderezos que cambian e o compoñente ao que se permite cambialos. Na conectividade de MuleSoft esa decisión ten tres entradas: se o backend necesita tradución de portos de moitos a un ou un alias de prefixo dun a un, se a conexión de AWS que realmente posúe pode facer esa asignación, e se todo o camiño queda dentro dunha combinación que o provedor admite. Se se equivoca, construirá un laboratorio que funciona pero falla na revisión.

O único punto fixo é que Anypoint VPN non é un dispositivo de tradución. A documentación de CloudHub 2.0 lista NAT como non admitido alí, así que calquera deseño que supoña que o túnel ocultará os enderezos dos seus traballadores xa está roto.

Decida que debe facer a tradución

Se moitos traballadores da aplicación deben aparecer ante o backend como unha soa dirección, o requisito é unha tradución de orixe compartida, normalmente SNAT ou PAT con estado nun cortalumes que vostede controle. Ese elemento debe estar nun camiño aprobado, conservar o seu estado durante toda a vida do fluxo e ver o tráfico de volta de cada conexión que reescribiu. Perder o estado no medio da sesión non degrada a conexión; termínaa. Un par de cortalumes que se nega a compartir o estado de tradución descartará cada sesión que tras o failover caia no membro de reserva. Dimensione ese elemento para fluxos concorrentes, non para rendemento.

Se en cambio dúas redes se solapan e cada host necesita un alias distinto, o requisito é un plan de enderezos dun a un con prefixos asignados inequívocos, rutas coincidentes e resolución de nomes que concorde coa asignación. Ocultar cada traballador tras unha soa dirección non é unha versión máis barata diso, e cambiar un polo outro nunha revisión de deseño é como os proxectos perden un trimestre.

Rexistre a decisión en termos concretos antes de elixir un produto: orixe orixinal, destino orixinal, valor traducido, dirección de inicio, propietario do tradutor e ruta de resposta esperada. Engada que identidade conservarán os rexistros do backend, porque un deseño que oculta todas as orixes tamén destrúe a auditoría por cliente.

Comprobe se AWS pode facer a asignación por vostede

AWS xa documenta NAT xestionado dun a un en conexións de Transit Gateway e Cloud WAN, anunciado a finais de outubro de 2026, así que a vella afirmación xeral de que unha pasarela de tránsito nunca pode traducir está desfasada. A documentación de Transit Gateway NAT describe unha asignación de prefixos IPv4 sen estado: os prefixos orixinais e traducidos manteñen a mesma lonxitude, e os bits de host e os portos de transporte sobreviven á tradución. Lea as direccións de entrada e saída como decisións de deseño separadas, porque se configuran por separado e unha pode estar lista mentres a outra non. Nada nesa descrición implica estado por fluxo, así que non espere que a asignación siga as conexións por vostede.

Isto significa que 10.80.0.0/16 asignado a 172.28.0.0/16 converte 10.80.10.23 en 172.28.10.23. Non colapsa o /16 nunha soa dirección nin substitúe un requisito de PAT. Tamén cobre tipos de conexión seleccionados, entre eles VPC e Site-to-Site VPN, pero non conexións de Client VPN, e a configuración vive co propietario da pasarela de tránsito, non co lado de Anypoint.

Trate a función como un punto de control posible máis, non como proba de que o seu despregamento poida usala. CloudHub 2.0 documenta conexións de espazo privado a unha pasarela de tránsito na propia conta de AWS do cliente, con condicións rexionais e de dereito, así que confirme o tipo real de conexión, o seu propietario e a posición de soporte do provedor antes de deseñar arredor da nova opción.

Manteña o camiño dentro dun límite admitido

Para un tradutor de cortalumes, use o modelo de VPN, tradución e encamiñamento admitido dese produto en lugar de pegar unha regra NAT xenérica nun túnel que funciona. A resposta do backend ten que volver polo mesmo elemento de tradución, e un túnel de saída san non di nada sobre esa ruta de volta.

Para a ruta da pasarela de tránsito, inventaríe a conexión de espazo privado, as táboas de rutas pertinentes, a conexión local e as pezas que o cliente realmente pode configurar. É outra arquitectura de conectividade, non unha caixa de NAT atornillada a unha conexión de Anypoint VPN existente, e o límite de soporte móvese con ela.

Compare as tres opcións nunha táboa

A maioría dos equipos só necesita responder dúas preguntas: moitos a un ou un a un, e quen posúe a conexión. A táboa seguinte converte esas respostas nunha opción inicial.

Lea a terceira columna como a pregunta da revisión, non como unha idea posterior. Un mapa de prefixos permitido sobre o papel pero configurado nunha conexión que vostede non posúe segue sendo un proxecto bloqueado, e unha regra PAT que deixa pasar o tráfico pero rompe o rexistro por cliente falla a auditoría que vén despois.

Valide a asignación antes de prometela

Enrute unha operación nova da aplicación polo camiño e confirme a resposta, non só a petición. Pregunte ao propietario do backend que dirección de orixe rexistraron os seus rexistros, comprobe que o tratamento da familia de enderezos coincide co plan en ambos os sentidos e verifique que unha ruta que debería denegarse segue a denegarse. Unha conexión antiga non demostra nada sobre a asignación que acaba de cambiar.

Manteña a autenticación do backend independente de cal dirección traducida satisfai a súa lista de permitidos, porque a asignación é fontanería de rede e non unha decisión de control de acceso. No momento en que un restablecemento de contrasinal dependa dun prefixo NAT, cada cambio futuro de rango convértese nunha caída.

Antes da aprobación, escriba as tres respostas: tipo de tradución, propietario do tradutor e a conexión ou ruta de produto admitida que a leva. Se algunha delas segue sendo unha suposición, o deseño non está listo para unha ventá de cambios.