Anypoint VPN o NAT sa Transit Gateway: saan nangyayari ang pagsasalin
Hindi mismo nagsasalin ng mga address ang Anypoint VPN. Pumili sa pagitan ng disenyong PAT sa firewall, mapa ng prefix ng AWS o ibang attachment bago mangako ng NAT.
Ang pangangailangan sa NAT ay hindi pangangailangan hanggang hindi nito pinapangalanan ang mga address na nagbabago at ang component na pinapayagang magbago sa mga ito. Sa konektibidad ng MuleSoft, may tatlong input ang desisyong iyon: kung kailangan ng backend ang marami-sa-isang port translation o isa-sa-isang prefix alias, kung kayang gawin ng AWS attachment na aktwal mong pagmamay-ari ang mapping na iyon, at kung nananatili ang buong landas sa loob ng kombinasyong sinusuportahan ng vendor. Kapag nagkamali, makakabuo ka ng laboratoryong gumagana ngunit bumabagsak sa review.
Ang tanging fixed point ay ang Anypoint VPN mismo ay hindi kagamitan sa pagsasalin. Inililista ng dokumentasyon ng CloudHub 2.0 ang NAT bilang hindi sinusuportahan doon, kaya anumang disenyong nagpapalagay na itatago ng tunnel ang mga address ng iyong mga worker ay sira na.
Magpasya kung ano ang dapat gawin ng pagsasalin
Kung maraming application worker ang dapat lumitaw sa backend bilang isang address, ang pangangailangan ay shared source translation, karaniwang stateful SNAT o PAT sa firewall na kontrolado mo. Dapat nakalagay ang elementong iyon sa aprubadong landas, panatilihin ang estado nito sa buong buhay ng flow, at makita ang return traffic ng bawat koneksyong muling isinulat nito. Ang pagkawala ng estado sa gitna ng session ay hindi nagpapabagsak sa koneksyon; tinatapos nito ito. Ang pares ng firewall na tumatangging magbahagi ng translation state ay babagsak sa bawat session na mapupunta sa standby member pagkatapos ng failover. Sukatin ang elementong iyon para sa sabay-sabay na flow, hindi para sa throughput.
Kung sa halip ay nag-o-overlap ang dalawang network at kailangan ng bawat host ang natatanging alias, ang pangangailangan ay isa-sa-isang plano ng address na may malinaw na na-map na prefix, tugmang ruta at resolusyon ng pangalan na umaayon sa mapping. Ang itago ang bawat worker sa likod ng isang address ay hindi mas murang bersyon niyon, at ang pagpapalit ng isa sa isa pa sa review ng disenyo ang paraan kung paano nawawalan ng quarter ang mga proyekto.
Itala ang desisyon sa konkretong termino bago pumili ng produkto: orihinal na source, orihinal na destinasyon, isinalin na halaga, direksyon ng pagsisimula, may-ari ng tagasalin at inaasahang ruta ng tugon. Idagdag kung anong identity ang pananatilihin ng mga log ng backend, dahil ang disenyong nagtatago sa lahat ng source ay sumisira rin sa audit kada kliyente.
Tingnan kung kayang gawin ng AWS ang mapping para sa iyo
Dokumentado na ngayon ng AWS ang managed na isa-sa-isang NAT sa mga attachment ng Transit Gateway at Cloud WAN, inihayag noong huling bahagi ng Oktubre 2026, kaya ang lumang pangkalahatang claim na hindi kailanman makakapagsalin ang transit gateway ay lipas na. Inilalarawan ng dokumentasyon ng Transit Gateway NAT ang stateless na IPv4 prefix mapping: pinapanatili ng orihinal at isinalin na prefix ang parehong haba, at nabubuhay ang host bits at transport port sa pagsasalin. Basahin ang ingress at egress na direksyon bilang magkahiwalay na desisyon sa disenyo, dahil magkahiwalay silang kino-configure at maaaring handa na ang isa habang hindi pa ang isa. Wala sa paglalarawang iyon ang nagpapahiwatig ng state kada flow, kaya huwag asahan na susubaybayan ng mapping ang mga koneksyon para sa iyo.
Ibig sabihin, ang 10.80.0.0/16 na naka-map sa 172.28.0.0/16 ay ginagawang 172.28.10.23 ang 10.80.10.23. Hindi nito pinipiga ang /16 sa isang address, at hindi nito pinapalitan ang pangangailangan sa PAT. Sakop din nito ang piling uri ng attachment, kabilang ang VPC at Site-to-Site VPN, ngunit hindi ang mga attachment ng Client VPN, at ang configuration ay nasa may-ari ng transit gateway, hindi sa panig ng Anypoint.
Tratuhin ang feature bilang isa pang posibleng control point, hindi bilang patunay na magagamit ito ng iyong deployment. Dokumentado ng CloudHub 2.0 ang mga attachment ng private space sa isang transit gateway sa sariling AWS account ng customer, na may rehiyonal at entitlement na kondisyon, kaya kumpirmahin ang tunay na uri ng attachment, ang may-ari nito at ang posisyon ng suporta ng vendor bago magdisenyo sa paligid ng bagong opsyon.
Panatilihin ang landas sa loob ng sinusuportahang hangganan
Para sa firewall translator, gamitin ang sinusuportahang modelo ng VPN, pagsasalin at routing ng produktong iyon sa halip na idikit ang generic na NAT rule sa gumaganang tunnel. Dapat bumalik ang tugon ng backend sa parehong element ng pagsasalin, at ang malusog na outbound tunnel ay walang sinasabi tungkol sa return path na iyon.
Para sa ruta ng transit gateway, i-inventory ang attachment ng private space, ang mga kaugnay na route table, ang on-premises attachment at ang mga bahaging aktwal na maaaring i-configure ng customer. Ito ay ibang arkitektura ng konektibidad, hindi checkbox ng NAT na naka-bolt sa umiiral na koneksyon ng Anypoint VPN, at gumagalaw kasama nito ang hangganan ng suporta.
Ihambing ang tatlong opsyon sa isang talahanayan
Karamihan sa mga team ay kailangan lamang sagutin ang dalawang tanong: marami-sa-isa o isa-sa-isa, at sino ang may-ari ng attachment. Ginagawang panimulang opsyon ng talahanayan sa ibaba ang mga sagot na iyon.
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
Basahin ang ikatlong hanay bilang tanong ng review, hindi bilang naisip pagkatapos. Ang prefix map na pinapayagan sa papel ngunit naka-configure sa attachment na hindi mo pagmamay-ari ay huli pa ring hinarang na proyekto, at ang PAT rule na nagpapalusot ng traffic ngunit sumisira sa logging kada kliyente ay bumabagsak sa audit na sumusunod.
Patunayan ang mapping bago mangako
Magpadala ng isang sariwang operasyon ng application sa landas at kumpirmahin ang tugon, hindi lamang ang kahilingan. Itanong sa may-ari ng backend kung anong source address ang naitala ng kanilang log, tingnan kung tugma ang paghawak ng address family sa plano sa parehong direksyon, at patunayan na ang landas na dapat tanggihan ay tinatanggihan pa rin. Walang pinapatunayan ang lumang koneksyon tungkol sa mapping na binago mo lang.
Panatilihing independiyente ang authentication ng backend sa kung aling isinalin na address ang tumutugon sa allowlist nito, dahil ang mapping ay plumbing ng network at hindi desisyon sa access control. Sa sandaling nakadepende ang pag-reset ng password sa NAT prefix, nagiging outage ang bawat pagbabago ng range sa hinaharap.
Bago ang pag-apruba, isulat ang tatlong sagot: uri ng pagsasalin, may-ari ng tagasalin, at ang sinusuportahang attachment o landas ng produkto na nagdadala nito. Kung hula pa rin ang alinman sa mga ito, hindi pa handa ang disenyo para sa window ng pagbabago.