Anypoint VPN eller Transit Gateway NAT: var översättningen sker

Ett NAT-krav är inte ett krav förrän det namnger adresserna som ändras och komponenten som får ändra dem. I MuleSoft-anslutning har det beslutet tre indata: om backend behöver många-till-ett-portöversättning eller ett ett-till-ett-prefixalias, om den AWS-anslutning du faktiskt äger kan utföra den mappningen, och om hela vägen stannar inom en kombination som leverantören stöder. Går det fel bygger du ett labb som fungerar men faller i granskningen.

Den enda fasta punkten är att Anypoint VPN självt inte är en översättningsenhet. CloudHub 2.0-dokumentationen listar NAT som ostött där, så varje design som antar att tunneln döljer dina arbetares adresser är redan trasig.

Bestäm vad översättningen ska göra

Om många applikationsarbetare måste framstå som en enda adress för backend är kravet delad källöversättning, vanligtvis tillståndsbevarande SNAT eller PAT på en brandvägg som du kontrollerar. Det elementet måste sitta på en godkänd väg, behålla sitt tillstånd under hela flödets livstid och se returtrafiken för varje anslutning det skrev om. Förlorat tillstånd mitt i en session försämrar inte anslutningen; det avslutar den. Ett brandväggspar som vägrar dela översättningstillstånd kommer att släppa varje session som efter failover landar på standbymedlemmen. Dimensionera det elementet för samtidiga flöden, inte för genomströmning.

Om två nätverk i stället överlappar och varje värd behöver ett eget alias är kravet en ett-till-ett-adressplan med entydiga mappade prefix, matchande rutter och namnmatchning som stämmer med mappningen. Att dölja varje arbetare bakom en enda adress är inte en billigare version av det, och att byta det ena mot det andra i en designgranskning är hur projekt förlorar ett kvartal.

Skriv ned beslutet i konkreta termer innan du väljer produkt: ursprunglig källa, ursprungligt mål, översatt värde, initieringsriktning, översättarens ägare och förväntad svarsväg. Lägg till vilken identitet backend-loggarna behåller, eftersom en design som döljer alla källor också förstör granskningen per klient.

Kontrollera om AWS kan göra mappningen åt dig

AWS dokumenterar nu hanterad ett-till-ett-NAT på Transit Gateway- och Cloud WAN-anslutningar, tillkännagivet i slutet av oktober 2026, så det gamla generella påståendet att en transitgateway aldrig kan översätta är föråldrat. Transit Gateway NAT-dokumentationen beskriver en tillståndslös IPv4-prefixmappning: ursprungliga och översatta prefix behåller samma längd, och värdbitar och transportportar överlever översättningen. Läs ingress- och egressriktningarna som separata designbeslut, eftersom de konfigureras separat och den ena kan vara klar medan den andra inte är det. Inget i den beskrivningen antyder tillstånd per flöde, så förvänta dig inte att mappningen följer anslutningar åt dig.

Det betyder att 10.80.0.0/16 mappat till 172.28.0.0/16 gör 10.80.10.23 till 172.28.10.23. Det pressar inte ihop /16 till en enda adress och ersätter inte ett PAT-krav. Det täcker också utvalda anslutningstyper, bland dem VPC och Site-to-Site VPN, men inte Client VPN-anslutningar, och konfigurationen ligger hos ägaren av transitgatewayen, inte på Anypoint-sidan.

Behandla funktionen som ytterligare en möjlig kontrollpunkt, inte som bevis för att din driftsättning kan använda den. CloudHub 2.0 dokumenterar private-space-anslutningar till en transitgateway i kundens eget AWS-konto, med regionala villkor och rättighetsvillkor, så bekräfta den verkliga anslutningstypen, dess ägare och leverantörens supportposition innan du designar kring det nya alternativet.

Håll vägen inom en stödd gräns

För en brandväggsöversättare, använd den stödda VPN-, översättnings- och routingmodellen för den produkten i stället för att klistra in en generisk NAT-regel i en fungerande tunnel. Backendens svar måste komma tillbaka genom samma översättningselement, och en frisk utgående tunnel säger ingenting om den returvägen.

För transitgateway-rutten, inventera private-space-anslutningen, de relevanta routingtabellerna, anslutningen på plats och de delar som kunden faktiskt kan konfigurera. Det är en annan anslutningsarkitektur, inte en NAT-kryssruta fastskruvad på en befintlig Anypoint VPN-anslutning, och supportgränsen flyttar med den.

Jämför de tre alternativen i en tabell

De flesta team behöver bara svara på två frågor: många-till-ett eller ett-till-ett, och vem som äger anslutningen. Tabellen nedan gör om svaren till ett startalternativ.

Läs den tredje kolumnen som granskningsfrågan, inte som en eftertanke. En prefixkarta som är tillåten på papperet men konfigurerad på en anslutning du inte äger är fortfarande ett blockerat projekt, och en PAT-regel som släpper igenom trafik men bryter loggningen per klient faller i revisionen som följer.

Validera mappningen innan du lovar den

Skicka en färsk applikationsoperation genom vägen och bekräfta svaret, inte bara begäran. Fråga backend-ägaren vilken källadress deras loggar registrerade, kontrollera att hanteringen av adressfamiljer stämmer med planen i båda riktningarna och verifiera att en väg som ska nekas fortfarande nekas. En gammal anslutning bevisar ingenting om mappningen du just ändrade.

Håll backend-autentisering oberoende av vilken översatt adress som uppfyller dess tillåtelselista, eftersom mappningen är nätverksrör och inte ett beslut om åtkomstkontroll. I samma stund som en lösenordsåterställning beror på ett NAT-prefix blir varje framtida intervalländring ett avbrott.

Före godkännandet, skriv ned de tre svaren: översättningstyp, översättarens ägare och den stödda anslutningen eller produktvägen som bär den. Om något av dem fortfarande är en gissning är designen inte klar för ett ändringsfönster.