Anypoint VPN aŭ NAT en Transit Gateway: kie okazas la tradukado

NAT-postulo ne estas postulo, ĝis ĝi nomas la adresojn, kiuj ŝanĝiĝas, kaj la komponanton, kiu rajtas ŝanĝi ilin. Ĉe MuleSoft-konekteco tiu decido havas tri enigojn: ĉu la backend bezonas mult-al-unu-pordan tradukadon aŭ unu-al-unu-prefiksan alinomon, ĉu la AWS-konektaĵo, kiun vi efektive posedas, povas fari tiun mapadon, kaj ĉu la tuta vojo restas en kombinaĵo, kiun la vendanto subtenas. Se vi eraras pri tio, vi konstruos laboratorion, kiu funkcias sed malsukcesas en la revizio.

La unu fiksa punkto estas, ke Anypoint VPN mem ne estas traduka aparato. La dokumentaro de CloudHub 2.0 listigas NAT kiel nesubtenatan tie, do ĉiu dezajno, kiu supozas, ke la tunelo kaŝos viajn laboristajn adresojn, jam estas difektita.

Difinu, kion la tradukado devas fari

Se multaj aplikaĵaj laboristoj devas aperi al la backend kiel unu adreso, la postulo estas komuna fonta tradukado, kutime stateful SNAT aŭ PAT sur fajroŝirmilo, kiun vi kontrolas. Tiu elemento devas stari sur aprobita vojo, konservi sian staton dum la tuta vivo de la fluo kaj vidi la revenan trafikon por ĉiu konekto, kiun ĝi reverkis. Perdo de stato meze de sesio ne malbonigas la konekton; ĝi finas ĝin. Paro da fajroŝirmiloj, kiu rifuzas dividi tradukan staton, faligos ĉiun sesion, kiu post la baskulo surteriĝas sur la rezerva membro. Dimensionu tiun elementon por samtempaj fluoj, ne por trafika kapacito.

Se kontraŭe du retoj interkovriĝas kaj ĉiu gastiganto bezonas apartan alinomon, la postulo estas unu-al-unu-adresa plano kun senduba mapitaj prefiksoj, kongruaj vojoj kaj nomrezolucio, kiu kongruas kun la mapado. Kaŝi ĉiun laboriston malantaŭ unu adreso ne estas pli malmultekosta versio de tio, kaj interŝanĝi unu kontraŭ la alia en dezajnrevizio estas la maniero, kiel projektoj perdas kvaronjaron.

Skribu la decidon per konkretaj terminoj antaŭ ol elekti produkton: origina fonto, origina celo, tradukita valoro, direkto de iniciato, posedanto de la tradukilo kaj atendata responda vojo. Aldonu, kiun identecon konservos la backend-Protokoloj, ĉar dezajno, kiu kaŝas ĉiujn fontojn, ankaŭ detruas revizion por ĉiu kliento.

Kontrolu, ĉu AWS povas fari la mapadon por vi

AWS nun dokumentas administritan unu-al-unu-NAT sur Transit Gateway kaj Cloud WAN-konektaĵoj, anoncitan fine de oktobro 2026, do la malnova ĝenerala aserto, ke traireja pordego neniam povas traduki, estas eksdata. La dokumentaro pri Transit Gateway NAT priskribas senstatan IPv4-prefiksan mapadon: originaj kaj tradukitaj prefiksoj konservas la saman longon, kaj gastigantaj bitoj kaj transportaj pordoj postvivas la tradukadon. Legu la enirajn kaj elirajn direktojn kiel apartajn dezajnajn decidojn, ĉar ili konfiguriĝas aparte kaj unu povas esti preta dum la alia ne. Nenio en tiu priskribo implicas staton por fluo, do ne atendu, ke la mapado spuros konektojn por vi.

Tio signifas, ke 10.80.0.0/16 mapita al 172.28.0.0/16 igas 10.80.10.23 je 172.28.10.23. Ĝi ne kunpremas la /16 en unu adreson kaj ne anstataŭigas PAT-postulon. Ĝi ankaŭ kovras elektitajn konektaĵtipojn, inter ili VPC kaj Site-to-Site VPN, sed ne Client VPN-konektaĵojn, kaj la agordo loĝas ĉe la posedanto de la traireja pordego, ne ĉe la flanko Anypoint.

Traktu la funkcion kiel plian eblan kontrolpunkton, ne kiel pruvon, ke via deplojo povas uzi ĝin. CloudHub 2.0 dokumentas privata-spacajn konektaĵojn al traireja pordego en la propra AWS-konto de la kliento, kun regionaj kondiĉoj kaj rajtigaj kondiĉoj, do konfirmu la realan konektaĵtipon, ĝian posedanton kaj la subtenan pozicion de la vendanto antaŭ ol dezajni ĉirkaŭ la nova opcio.

Tenu la vojon ene de subtenata limo

Por fajroŝirmila tradukilo, uzu la subtenatan VPN-, tradukan kaj vojigan modelon de tiu produkto anstataŭ englui ĝeneralan NAT-regulon en funkciantan tunnelon. La respondo de la backend devas reveni tra la sama traduka elemento, kaj sana elira tunelo diras nenion pri tiu revena vojo.

Por la traireja pordega vojo, inventaru la privata-spacan konektaĵon, la koncernajn vojigajn tabelojn, la surlokan konektaĵon kaj la partojn, kiujn la kliento efektive povas agordi. Ĝi estas alia konekteca arkitekturo, ne NAT-markobutono ŝraŭbita sur ekzistantan Anypoint VPN-konekton, kaj la subtena limo moviĝas kun ĝi.

Komparu la tri opciojn en unu tabelo

Plej multaj teamoj bezonas respondi nur du demandojn: mult-al-unu aŭ unu-al-unu, kaj kiu posedas la konektaĵon. La suba tabelo transformas tiujn respondojn en komencan opcion.

Legu la trian kolumnon kiel la revizian demandon, ne kiel postpensan aldonaĵon. Prefiksa mapo permesita surpapera sed agordita sur konektaĵo, kiun vi ne posedas, restas blokita projekto, kaj PAT-regulo, kiu pasigas trafikon sed rompas protokoladon por ĉiu kliento, malsukcesas en la revizio, kiu sekvas.

Validigu la mapadon antaŭ ol promesi ĝin

Sendu unu novan aplikaĵan operacion tra la vojo kaj konfirmu la respondon, ne nur la peton. Demandu la backend-posedanton, kiun fontan adreson registris iliaj protokoloj, kontrolu, ke la traktado de adresa familio kongruas kun la plano en ambaŭ direktoj, kaj certigu, ke unu vojo, kiu devus esti rifuzata, ankoraŭ estas rifuzata. Malnova konekto pruvas nenion pri la mapado, kiun vi ĵus ŝanĝis.

Tenu backend-aŭtentikigon sendependa de tio, kiu tradukita adreso kontentigas ĝian permesliston, ĉar la mapado estas reta instalaĵo kaj ne decido pri alirkontrolo. En la momento, kiam pasvortorestarigo dependas de NAT-prefikso, ĉiu estonta gamoŝanĝo iĝas paneo.

Antaŭ la aprobo, skribu la tri respondojn: traduka tipo, posedanto de la tradukilo kaj la subtenata konektaĵo aŭ produkta vojo, kiu portas ĝin. Se iu el ili ankoraŭ estas konjekto, la dezajno ne pretas por ŝanĝfenestro.