Anypoint VPN ou NAT no Transit Gateway: onde a tradução acontece

Um requisito de NAT não é requisito até nomear os endereços que mudam e o componente autorizado a mudá-los. Na conectividade MuleSoft essa decisão tem três entradas: se o backend precisa de tradução de portas muitos-para-um ou de um alias de prefixo um-para-um, se a conexão AWS que você realmente possui pode fazer esse mapeamento, e se todo o caminho permanece dentro de uma combinação suportada pelo fornecedor. Se errar isso, você construirá um laboratório que funciona mas reprova na revisão.

O único ponto fixo é que o próprio Anypoint VPN não é um dispositivo de tradução. A documentação do CloudHub 2.0 lista NAT como não suportado ali, então qualquer projeto que presuma que o túnel esconderá os endereços dos seus workers já está quebrado.

Decida o que a tradução precisa fazer

Se muitos workers de aplicação precisam aparecer para o backend como um único endereço, o requisito é tradução de origem compartilhada, geralmente SNAT ou PAT com estado em um firewall que você controla. Esse elemento precisa ficar em um caminho aprovado, manter seu estado durante toda a vida do fluxo e ver o tráfego de retorno de cada conexão que reescreveu. Perder o estado no meio da sessão não degrada a conexão; ela a encerra. Um par de firewalls que se recusa a compartilhar estado de tradução descartará toda sessão que cair no membro de standby após o failover. Dimensione esse elemento para fluxos simultâneos, não para taxa de transferência.

Se, em vez disso, duas redes se sobrepõem e cada host precisa de um alias distinto, o requisito é um plano de endereços um-para-um com prefixos mapeados sem ambiguidade, rotas correspondentes e resolução de nomes coerente com o mapeamento. Esconder cada worker atrás de um único endereço não é uma versão mais barata disso, e trocar um pelo outro em uma revisão de projeto é como os projetos perdem um trimestre.

Registre a decisão em termos concretos antes de escolher um produto: origem original, destino original, valor traduzido, direção de iniciação, proprietário do tradutor e rota de resposta esperada. Acrescente qual identidade os logs do backend vão manter, porque um projeto que esconde todas as origens também destrói a auditoria por cliente.

Verifique se a AWS pode fazer o mapeamento por você

A AWS agora documenta NAT gerenciado um-para-um em conexões Transit Gateway e Cloud WAN, anunciado no fim de outubro de 2026, então a antiga afirmação genérica de que um gateway de trânsito nunca pode traduzir está desatualizada. A documentação do Transit Gateway NAT descreve um mapeamento de prefixos IPv4 sem estado: prefixos originais e traduzidos mantêm o mesmo comprimento, e bits de host e portas de transporte sobrevivem à tradução. Leia as direções de entrada e saída como decisões de projeto separadas, porque são configuradas separadamente e uma pode estar pronta enquanto a outra não. Nada nessa descrição implica estado por fluxo, então não espere que o mapeamento acompanhe conexões por você.

Isso significa que 10.80.0.0/16 mapeado para 172.28.0.0/16 transforma 10.80.10.23 em 172.28.10.23. Ele não colapsa o /16 em um único endereço e não substitui um requisito de PAT. Também cobre tipos de conexão selecionados, entre eles VPC e Site-to-Site VPN, mas não conexões Client VPN, e a configuração fica com o proprietário do gateway de trânsito, não com o lado Anypoint.

Trate o recurso como mais um ponto de controle possível, não como prova de que sua implantação pode usá-lo. O CloudHub 2.0 documenta conexões de espaço privado a um gateway de trânsito na própria conta AWS do cliente, com condições regionais e de direito, então confirme o tipo real de conexão, seu proprietário e a posição de suporte do fornecedor antes de projetar em torno da nova opção.

Mantenha o caminho dentro de um limite suportado

Para um tradutor no firewall, use o modelo de VPN, tradução e roteamento suportado desse produto em vez de colar uma regra NAT genérica em um túnel que funciona. A resposta do backend precisa voltar pelo mesmo elemento de tradução, e um túnel de saída saudável não diz nada sobre esse caminho de volta.

Para a rota do gateway de trânsito, inventeie a conexão de espaço privado, as tabelas de rotas relevantes, a conexão local e as partes que o cliente realmente pode configurar. É outra arquitetura de conectividade, não uma caixa de NAT aparafusada a uma conexão Anypoint VPN existente, e o limite de suporte se move com ela.

Compare as três opções em uma tabela

A maioria das equipes só precisa responder a duas perguntas: muitos-para-um ou um-para-um, e quem é o dono da conexão. A tabela abaixo transforma essas respostas em uma opção inicial.

Leia a terceira coluna como a pergunta da revisão, não como um pensamento posterior. Um mapa de prefixos permitido no papel mas configurado em uma conexão que você não possui continua sendo um projeto bloqueado, e uma regra PAT que deixa o tráfego passar mas quebra o registro por cliente reprova na auditoria seguinte.

Valide o mapeamento antes de prometê-lo

Envie uma nova operação de aplicação pelo caminho e confirme a resposta, não apenas a requisição. Pergunte ao proprietário do backend qual endereço de origem os logs dele registraram, verifique se o tratamento da família de endereços corresponde ao plano nas duas direções e confirme que um caminho que deveria ser negado continua negado. Uma conexão antiga não prova nada sobre o mapeamento que você acabou de mudar.

Mantenha a autenticação do backend independente de qual endereço traduzido satisfaz a lista de permitidos, porque o mapeamento é encanamento de rede e não uma decisão de controle de acesso. No momento em que a redefinição de senha depender de um prefixo NAT, toda mudança futura de faixa se torna uma indisponibilidade.

Antes da aprovação, escreva as três respostas: tipo de tradução, proprietário do tradutor e a conexão ou caminho de produto suportado que a carrega. Se alguma delas ainda for um palpite, o projeto não está pronto para uma janela de mudanças.