Anypoint VPN o NAT de Transit Gateway: dónde se traduce
Anypoint VPN no traduce las direcciones por sí mismo. Decida entre un diseño PAT en el cortafuegos, un mapa de prefijos de AWS u otra conexión antes de prometer NAT.
Un requisito de NAT no es un requisito hasta que nombra las direcciones que cambian y el componente al que se permite cambiarlas. En la conectividad de MuleSoft esa decisión tiene tres entradas: si el backend necesita traducción de puertos de muchos a uno o un alias de prefijo de uno a uno, si la conexión de AWS que realmente posee puede hacer ese mapeo y si toda la ruta se queda dentro de una combinación que el proveedor admite. Si se equivoca, construirá un laboratorio que funciona pero falla en la revisión.
El único punto fijo es que Anypoint VPN no es un dispositivo de traducción. La documentación de CloudHub 2.0 enumera NAT como no admitido allí, así que cualquier diseño que suponga que el túnel ocultará las direcciones de sus workers ya está roto.
Decida qué debe hacer la traducción
Si muchos workers de la aplicación deben aparecer ante el backend como una sola dirección, el requisito es una traducción de origen compartida, normalmente SNAT o PAT con estado en un cortafuegos que usted controle. Ese elemento debe estar en una ruta aprobada, conservar su estado durante toda la vida del flujo y ver el tráfico de vuelta de cada conexión que reescribió. Perder el estado a mitad de sesión no degrada la conexión; la termina. Un par de cortafuegos que se niega a compartir el estado de traducción descartará cada sesión que tras el failover caiga en el miembro de reserva. Dimensione ese elemento para flujos concurrentes, no para rendimiento.
Si en cambio dos redes se solapan y cada host necesita un alias distinto, el requisito es un plan de direcciones de uno a uno con prefijos mapeados inequívocos, rutas coincidentes y resolución de nombres que concuerde con el mapeo. Ocultar cada worker tras una sola dirección no es una versión más barata de eso, y cambiar uno por otro en una revisión de diseño es como los proyectos pierden un trimestre.
Registre la decisión en términos concretos antes de elegir un producto: origen original, destino original, valor traducido, dirección de inicio, propietario del traductor y ruta de respuesta esperada. Añada qué identidad conservarán los registros del backend, porque un diseño que oculta todos los orígenes también destruye la auditoría por cliente.
Compruebe si AWS puede hacer el mapeo por usted
AWS ya documenta NAT gestionado de uno a uno en conexiones de Transit Gateway y Cloud WAN, anunciado a finales de octubre de 2026, así que la vieja afirmación general de que una puerta de enlace de tránsito nunca puede traducir está desfasada. La documentación de Transit Gateway NAT describe un mapeo de prefijos IPv4 sin estado: los prefijos originales y traducidos mantienen la misma longitud, y los bits de host y los puertos de transporte sobreviven a la traducción. Lea las direcciones de entrada y salida como decisiones de diseño separadas, porque se configuran por separado y una puede estar lista mientras la otra no. Nada en esa descripción implica estado por flujo, así que no espere que el mapeo siga las conexiones por usted.
Eso significa que 10.80.0.0/16 mapeado a 172.28.0.0/16 convierte 10.80.10.23 en 172.28.10.23. No colapsa el /16 en una sola dirección ni sustituye un requisito de PAT. También cubre tipos de conexión seleccionados, entre ellos VPC y Site-to-Site VPN, pero no conexiones de Client VPN, y la configuración vive con el propietario de la puerta de enlace de tránsito, no con el lado de Anypoint.
Trate la función como un punto de control posible más, no como prueba de que su despliegue pueda usarla. CloudHub 2.0 documenta conexiones de espacio privado a una puerta de enlace de tránsito en la propia cuenta de AWS del cliente, con condiciones regionales y de derecho, así que confirme el tipo real de conexión, su propietario y la posición de soporte del proveedor antes de diseñar en torno a la nueva opción.
Mantenga la ruta dentro de un límite admitido
Para un traductor de cortafuegos, use el modelo de VPN, traducción y enrutamiento admitido de ese producto en lugar de pegar una regla NAT genérica en un túnel que funciona. La respuesta del backend tiene que volver por el mismo elemento de traducción, y un túnel de salida sano no dice nada sobre esa ruta de vuelta.
Para la ruta de la puerta de enlace de tránsito, inventaríe la conexión de espacio privado, las tablas de rutas pertinentes, la conexión local y las piezas que el cliente realmente puede configurar. Es otra arquitectura de conectividad, no una casilla de NAT atornillada a una conexión de Anypoint VPN existente, y el límite de soporte se mueve con ella.
Compare las tres opciones en una tabla
La mayoría de los equipos solo necesita responder dos preguntas: muchos a uno o uno a uno, y quién posee la conexión. La tabla siguiente convierte esas respuestas en una opción inicial.
| 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 |
Lea la tercera columna como la pregunta de revisión, no como una idea posterior. Un mapa de prefijos permitido sobre el papel pero configurado en una conexión que usted no posee sigue siendo un proyecto bloqueado, y una regla PAT que deja pasar el tráfico pero rompe el registro por cliente falla la auditoría que viene después.
Valide el mapeo antes de prometerlo
Enrute una operación nueva de la aplicación por la ruta y confirme la respuesta, no solo la petición. Pregunte al propietario del backend qué dirección de origen registraron sus logs, compruebe que el tratamiento de la familia de direcciones coincide con el plan en ambos sentidos y verifique que una ruta que debería denegarse sigue denegándose. Una conexión antigua no demuestra nada sobre el mapeo que acaba de cambiar.
Mantenga la autenticación del backend independiente de cuál dirección traducida satisface su lista de permitidos, porque el mapeo es fontanería de red y no una decisión de control de acceso. En el momento en que un restablecimiento de contraseña dependa de un prefijo NAT, cada cambio futuro de rango se convierte en una caída.
Antes de la aprobación, escriba las tres respuestas: tipo de traducción, propietario del traductor y la conexión o ruta de producto admitida que la soporta. Si alguna de ellas sigue siendo una suposición, el diseño no está listo para una ventana de cambios.