Et NAT-krav er ikke et krav før det navngir adressene som endres og komponenten som har lov til å endre dem. I MuleSoft-tilkobling har den beslutningen tre innganger: om backend trenger mange-til-en-portoversettelse eller et en-til-en-prefiksalias, om AWS-tilkoblingen du faktisk eier kan utføre den mappingen, og om hele veien holder seg innenfor en kombinasjon leverandøren støtter. Går dette galt, bygger du et laboratorium som fungerer, men som feiler i gjennomgangen.

Det ene faste punktet er at Anypoint VPN selv ikke er en oversettelsesenhet. CloudHub 2.0-dokumentasjonen lister NAT som ikke støttet der, så ethvert design som antar at tunnelen skjuler arbeidernes adresser, er allerede ødelagt.

Avgjør hva oversettelsen skal gjøre

Hvis mange applikasjonsarbeidere må fremstå som én adresse for backend, er kravet delt kildeoversettelse, vanligvis tilstandsbevarende SNAT eller PAT på en brannmur du kontrollerer. Det elementet må sitte på en godkjent vei, holde tilstanden sin gjennom hele flytens levetid og se returtrafikken for hver tilkobling det skrev om. Tap av tilstand midt i en sesjon svekker ikke tilkoblingen; den avslutter den. Et brannmurpar som nekter å dele oversettelsestilstand, vil droppe hver sesjon som etter failover lander på reserveenheten. Dimensjoner det elementet for samtidige flyter, ikke for gjennomstrømning.

Hvis to nettverk overlapper og hver vert trenger et eget alias, er kravet en en-til-en-adresseplan med entydige mappede prefikser, samsvarende ruter og navneoppslag som stemmer med mappingen. Å skjule hver arbeider bak én adresse er ikke en billigere versjon av dette, og å bytte det ene mot det andre i en designgjennomgang er måten prosjekter mister et kvartal på.

Skriv ned beslutningen i konkrete termer før du velger produkt: opprinnelig kilde, opprinnelig destinasjon, oversatt verdi, initieringsretning, eier av oversetteren og forventet svarvei. Legg til hvilken identitet backend-loggene vil beholde, fordi et design som skjuler alle kilder også ødelegger revisjonen per klient.

Kontroller om AWS kan gjøre mappingen for deg

AWS dokumenterer nå administrert en-til-en-NAT på Transit Gateway- og Cloud WAN-tilkoblinger, kunngjort i slutten av oktober 2026, så den gamle generelle påstanden om at en transit gateway aldri kan oversette, er utdatert. Transit Gateway NAT-dokumentasjonen beskriver en tilstandsløs IPv4-prefiksmapping: opprinnelige og oversatte prefikser beholder samme lengde, og vertsbiter og transportporter overlever oversettelsen. Les ingress- og egressretningene som separate designbeslutninger, fordi de konfigureres separat, og den ene kan være klar mens den andre ikke er. Ingenting i den beskrivelsen antyder tilstand per flyt, så ikke forvent at mappingen følger tilkoblinger for deg.

Det betyr at 10.80.0.0/16 mappet til 172.28.0.0/16 gjør 10.80.10.23 til 172.28.10.23. Det kollapser ikke /16 til én adresse og erstatter ikke et PAT-krav. Det dekker også utvalgte tilkoblingstyper, blant dem VPC og Site-to-Site VPN, men ikke Client VPN-tilkoblinger, og konfigurasjonen ligger hos eieren av transit gateway, ikke på Anypoint-siden.

Behandle funksjonen som ett mulig kontrollpunkt til, ikke som bevis på at utrullingen din kan bruke den. CloudHub 2.0 dokumenterer private-space-tilkoblinger til en transit gateway i kundens eget AWS-konto, med regionale vilkår og rettighetsvilkår, så bekreft den reelle tilkoblingstypen, dens eier og leverandørens støtteposisjon før du designer rundt det nye alternativet.

Hold veien innenfor en støttet grense

For en brannmur-oversetter bruker du det støttede VPN-, oversettelses- og rutingsmodellen til det produktet i stedet for å lime en generisk NAT-regel inn i en fungerende tunnel. Svaret fra backend må komme tilbake gjennom det samme oversettelseselementet, og en sunn utgående tunnel sier ingenting om den returveien.

For transit gateway-ruten: inventoriser private-space-tilkoblingen, de relevante rutetabellene, tilkoblingen på stedet og delene kunden faktisk kan konfigurere. Det er en annen tilkoblingsarkitektur, ikke en NAT-avkrysningsboks boltet på en eksisterende Anypoint VPN-tilkobling, og støttegrensen flytter seg med den.

Sammenlign de tre alternativene i én tabell

De fleste team trenger bare å svare på to spørsmål: mange-til-en eller en-til-en, og hvem som eier tilkoblingen. Tabellen nedenfor gjør svarene om til et startalternativ.

RequirementStarting optionWhat breaks it
Many workers, one backend addressStateful PAT on your firewallAsymmetric return path, expired state
Overlapping /16s, one-to-oneAWS prefix mapping on a supported attachmentClient VPN attachment, no explicit config
Per-client audit must surviveKeep original sources, translate downstreamAny many-to-one hiding of sources

Les den tredje kolonnen som gjennomgangsspørsmålet, ikke som en ettertanke. Et prefikskart som er tillatt på papiret, men konfigurert på en tilkobling du ikke eier, er fortsatt et blokkert prosjekt, og en PAT-regel som slipper trafikk gjennom, men ødelegger logging per klient, feiler i revisjonen som følger.

Valider mappingen før du lover den

Send én fersk applikasjonsoperasjon gjennom veien og bekreft svaret, ikke bare forespørselen. Spør backend-eieren hvilken kildeadresse loggene deres registrerte, kontroller at håndteringen av adressefamilier stemmer med planen i begge retninger, og verifiser at én vei som skal avvises fortsatt avvises. En gammel tilkobling beviser ingenting om mappingen du nettopp endret.

Hold backend-autentisering uavhengig av hvilken oversatt adresse som oppfyller tillatelseslisten, fordi mappingen er nettverksrørleggerarbeid og ikke en tilgangskontrollbeslutning. I det øyeblikket en passordtilbakestilling avhenger av et NAT-prefiks, blir enhver fremtidig områdeendring et avbrudd.

Før godkjenning noterer du de tre svarene: oversettelsestype, eier av oversetteren og den støttede tilkoblingen eller produktveien som bærer den. Hvis ett av dem fortsatt er en gjetning, er designet ikke klart for et endringsvindu.

Relaterte artikler