Anypoint VPN eller Transit Gateway NAT: kvar omsetjinga skjer

Eit NAT-krav er ikkje eit krav før det namngjev adressene som endrar seg og komponenten som har lov til å endre dei. I MuleSoft-tilkopling har den avgjerda tre inngangar: om backend treng mange-til-ein-portomsetjing eller eit ein-til-ein-prefiksalias, om AWS-tilkoplinga du faktisk eig kan utføre den mappinga, og om heile vegen held seg innanfor ein kombinasjon leverandøren støttar. Går dette gale, byggjer du eit laboratorium som fungerer, men som fell i gjennomgangen.

Det eine faste punktet er at Anypoint VPN sjølv ikkje er eining for omsetjing. CloudHub 2.0-dokumentasjonen listar NAT som ikkje støtta der, så kva som helst design som føreset at tunnelen skjuler adressene til arbeidarane dine, er alt øydelagt.

Avgjer kva omsetjinga skal gjere

Viss mange applikasjonsarbeidarar må framstå som éi adresse for backend, er kravet delt kjeldeomsetjing, vanlegvis tilstandsbevarande SNAT eller PAT på ein brannmur du styrer. Det elementet må sitje på ein godkjend veg, halde tilstanden sin gjennom heile levetida til flyten og sjå returtrafikken for kvar tilkopling det skreiv om. Tap av tilstand midt i ei økt svekkjer ikkje tilkoplinga; det avsluttar ho. Eit brannmurpar som nektar å dele omsetjingstilstand, vil droppe kvar økt som etter failover landar på reserveeininga. Dimensjoner det elementet for samtidige flytar, ikkje for gjennomstrøyming.

Viss to nettverk overlappar og kvar vert treng eit eige alias, er kravet ein ein-til-ein-adresseplan med eintydige mappa prefiks, samsvarande ruter og namneoppslag som stemmer med mappinga. Å skjule kvar arbeidar bak éi adresse er ikkje ein billegare versjon av dette, og å byte det eine mot det andre i ein designgjennomgang er måten prosjekt mistar eit kvartal på.

Skriv ned avgjerda i konkrete termar før du vel produkt: opphavleg kjelde, opphavleg mål, omsett verdi, initieringsretning, eigar av omsetjaren og forventa svarveg. Legg til kva identitet backend-loggene vil behalde, fordi eit design som skjuler alle kjelder også øydelegg revisjonen per klient.

Sjekk om AWS kan gjere mappinga for deg

AWS dokumenterer no administrert ein-til-ein-NAT på Transit Gateway- og Cloud WAN-tilkoplingar, kunngjort i slutten av oktober 2026, så den gamle generelle påstanden om at ein transittgateway aldri kan omsetje, er utdatert. Transit Gateway NAT-dokumentasjonen skildrar ei tilstandslaus IPv4-prefiksmapping: opphavlege og omsette prefiks held same lengd, og vertsbitar og transportportar overlever omsetjinga. Les ingress- og egressretningane som separate designavgjerder, fordi dei blir konfigurerte separat, og den eine kan vere klar medan den andre ikkje er det. Ingenting i den skildringa tilseier tilstand per flyt, så ikkje rekna med at mappinga følgjer tilkoplingar for deg.

Det tyder at 10.80.0.0/16 mappa til 172.28.0.0/16 gjer 10.80.10.23 til 172.28.10.23. Det pressar ikkje /16 saman til éi adresse og erstattar ikkje eit PAT-krav. Det dekkjer også utvalde tilkoplingstypar, mellom dei VPC og Site-to-Site VPN, men ikkje Client VPN-tilkoplingar, og konfigurasjonen ligg hos eigaren av transittgatewayen, ikkje på Anypoint-sida.

Behandle funksjonen som eit mogleg kontrollpunkt til, ikkje som prov på at utrullinga di kan bruke han. CloudHub 2.0 dokumenterer private-space-tilkoplingar til ein transittgateway i kundens eigen AWS-konto, med regionale vilkår og rettsvilkår, så stadfest den reelle tilkoplingstypen, eigaren hans og støttehaldninga til leverandøren før du designar rundt det nye alternativet.

Hald vegen innanfor ei støtta grense

For ein brannmur-omsetjar brukar du den støtta VPN-, omsetjings- og rutemodellen til det produktet i staden for å lime ei generisk NAT-regel inn i ein fungerande tunnel. Svaret frå backend må kome tilbake gjennom det same omsetjingselementet, og ein sunn utgåande tunnel seier ingenting om den returvegen.

For transittgateway-ruta: inventer private-space-tilkoplinga, dei relevante rutetabellane, tilkoplinga på staden og delane kunden faktisk kan konfigurere. Det er ein annan tilkoplingsarkitektur, ikkje ein NAT-avkryssingsboks bolta på ei eksisterande Anypoint VPN-tilkopling, og støttegrensa flyttar seg med han.

Samanlikn dei tre alternativa i éin tabell

Dei fleste team treng berre å svare på to spørsmål: mange-til-ein eller ein-til-ein, og kven som eig tilkoplinga. Tabellen nedanfor gjer svara om til eit startalternativ.

Les den tredje kolonnen som gjennomgangsspørsmålet, ikkje som ein ettertanke. Eit prefikskart som er tillate på papiret, men konfigurert på ei tilkopling du ikkje eig, er framleis eit blokkert prosjekt, og ei PAT-regel som slepp trafikken gjennom, men øydelegg logging per klient, fell i revisjonen som følgjer.

Valider mappinga før du lovar ho

Send éin fersk applikasjonsoperasjon gjennom vegen og stadfest svaret, ikkje berre førespurnaden. Spør backend-eigaren kva kjeldeadresse loggane deira registrerte, kontroller at handsaminga av adressefamiliar stemmer med planen i båe retningar, og verifiser at ein veg som skal avvisast framleis blir avvist. Ei gamal tilkopling provar ingenting om mappinga du nettopp endra.

Hald backend-autentisering uavhengig av kva omsett adresse som oppfyller tillatingslista, fordi mappinga er nettverksrøyrleggjararbeid og ikkje ei avgjerd om tilgangskontroll. I det augeblikket ein passordnullstilling avheng av eit NAT-prefiks, blir kvar framtidig områdeendring eit avbrot.

Før godkjenning skriv du ned dei tre svara: omsetjingstype, eigar av omsetjaren og den støtta tilkoplinga eller produktvegen som ber ho. Viss eitt av dei framleis er ei gissing, er designet ikkje klart for eit endringsvindauge.