Anypoint VPN یا په Transit Gateway کې NAT: ژباړه چېرته کېږي
Anypoint VPN پخپله پتې نه ژباړي. د NAT ژمنې له ورکولو مخکې د فایر وال PAT، د AWS د مخکښو نقشې یا بلې اړیکې ترمنځ انتخاب وکړئ.
د NAT اړتیا هغه مهال اړتیا نه ده ترڅو هغه پتې ونه نومي چې بدلېږي او هغه برخه چې د هغوی د بدلولو اجازه لري. په MuleSoft اړیکه کې دا پرېکړه درې ننوتل لري: آیا backend ته د ډېرو-له-یوه پورت ژباړه پکار ده که یو-له-یوه د مخکښ نوم، آیا هغه AWS اړیکه چې تاسو واقعاً لرئ هغه نقشه کول کولی شي، او آیا ټوله لار د پلورونکي په ملاتړ شوې ترکیب کې پاتې کېږي. که دا غلط شي، تاسو یو فعاله خو د بیاکتنې په پړاو کې ناکامه لابراتوار جوړوئ.
یوازینی ثابت ټکی دا دی چې Anypoint VPN پخپله د ژباړې وسیله نه ده. د CloudHub 2.0 اسناد هلته NAT د ناملاتړشوي په توګه لیست کوي، نو هره هغه طرحه چې فرض کوي تونل به ستاسو د کارګرانو پتې پټې کړي، لا له وړاندې ماتې ده.
پرېکړه وکړئ چې ژباړه څه وکړي
که ډېری د اپلیکیشن کارګران باید د backend په وړاندې د یوې پتې په توګه ښکاره شي، اړتیا شریکه سرچینه ژباړه ده، معمولاً په هغه فایر وال کې د حالت ساتونکی SNAT یا PAT چې تاسو یې کنټرولوئ. هغه برخه باید په منل شوې لار کې کېني، د جریان په ټول ژوند کې خپل حالت وساتي او د هر هغه اړیکې د بېرته راتلو ترافیک وویني چې بیا لیکلې یې ده. د غونډې په منځ کې د حالت له لاسه ورکول اړیکه نه کموي؛ هغه پای ته رسوي. د فایر والونو یوه جوړه چې د ژباړې حالت شریکولو ته انکار وکړي، هره هغه غونډه به وغورځوي چې د بدلون وروسته پرې ریزرف غړی راځي. هغه برخه د یووخت جریانونو لپاره اندازه کړئ، نه د تېرېدو وړتیا لپاره.
که پر ځای یې دوه شبکه یو بل ته ننوځي او هر هوسټ جلا نوم ته اړتیا لري، اړتیا یو-له-یوه د پتو پلان دی چې روښانه نقشه شوې مخکښې، سمون خوړونکي لارې او د نقشې سره سم د نومونو حل ولري. هر کارګر د یوې پتې شاته پټول د دې ارزانه بڼه نه ده، او په ډیزاین بیاکتنه کې یو بل ته بدلول هغه لار ده چې پروژې یوه ربعه له لاسه ورکوي.
له محصول غوره کولو مخکې پرېکړه په ټکو وټکو ولیکئ: اصلي سرچینه، اصلي منزل، ژباړل شوی ارزښت، د پیل لوری، د ژباړونکي مالک او تمه کېدونکې د ځواب لار. دا هم اضافه کړئ چې د backend لاګونه کومه پېژندنه ساتي، ځکه هغه ډیزاین چې ټولې سرچینې پټوي، د هر پیرودونکي پلټنه هم له منځه وړي.
وګورئ چې AWS ستاسو لپاره نقشه کول کولی شي که نه
AWS اوس په Transit Gateway او Cloud WAN اړیکو کې مدیریت شوې یو-له-یوه NAT مستند کوي، چې د 2026 اکتوبر په پای کې اعلان شو، نو هغه زوړ عمومي ادعا چې ټرانزیټ دروازه هېڅکله ژباړه نه شي کولی، نوره پخوانۍ ده. د Transit Gateway NAT اسناد بې حالته د IPv4 مخکښو نقشه کول بیانوي: اصلي او ژباړل شوې مخکښې یو شان اوږدوالی ساتي، او د هوسټ بټونه او د لېږد پورټونه له ژباړې ژغورل کېږي. د ننوتلو او وتلو لوري دوه جلا ډیزاین پرېکړې ولولئ، ځکه دوی جلا تنظیمیږي او یو ممکن چمتو وي او بل نه. په هغه بیان کې هېڅ شی د هر جریان حالت نه ښیي، نو مه تمه کوئ چې نقشه به ستاسو لپاره اړیکې تعقیب کړي.
دا مانا دا ده چې 10.80.0.0/16 چې 172.28.0.0/16 ته نقشه شوی وي، 10.80.10.23 په 172.28.10.23 بدلوي. دا /16 په یوه پته نه غونډوي او د PAT اړتیا نه بدلوي. دا همدارنګه ټاکل شوي اړیکې ډولونه رانغاړي، چې VPC او Site-to-Site VPN پکې دي، خو د Client VPN اړیکې نه، او تنظیمات د Anypoint اړخ نه، د ټرانزیټ دروازې مالک سره دي.
دا ځانګړنه د بل ممکن کنټرول ټکي په توګه وګورئ، نه د دې ثبوت چې ستاسو ځای پرځای کول یې کارولی شي. CloudHub 2.0 په پیرودونکي خپل AWS حساب کې ټرانزیټ دروازې ته د خصوصي تشې اړیکې د سیمه ییزو او حق شرایطو سره مستند کوي، نو د نوي انتخاب شاوخوا ډیزاین کولو مخکې اصلي اړیکې ډول، مالک او د پلورونکي د ملاتړ دریځ تایید کړئ.
لاره د ملاتړ شوې پولې په داخل کې وساتئ
د فایر وال ژباړونکي لپاره، پر فعال تونل کې عمومي NAT قاعده نښلولو پر ځای د هغه محصول ملاتړ شوی VPN، ژباړه او لارښوونه ماډل وکاروئ. د backend ځواب باید د هماغه ژباړې برخې له لارې بېرته راشي، او روغه وتونکې تونل د هغه بېرته راتلو لارې په اړه هېڅ نه وایي.
د ټرانزیټ دروازې لارې لپاره، د خصوصي تشې اړیکه، اړوندې لارښود جدولونه، په ځای اړیکه او هغه برخې چې پیرودونکی یې واقعاً تنظیمولی شي لیست کړئ. دا بېله اړیکې معماري ده، نه هغه د NAT چیک بکس چې پر موجوده Anypoint VPN اړیکه تړل شوی، او د ملاتړ پوله ورسره ځي.
درې انتخابونه په یوه جدول کې پرتله کړئ
ډېری ټیمونه یوازې دوه پوښتنو ته ځواب ورکوي: ډېر-له-یوه که یو-له-یوه، او د اړیکې مالک څوک دی. لاندې جدول هغه ځوابونه په پیلېدونکي انتخاب بدلوي.
| 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 |
دریمه کالم د وروستي فکر په توګه نه، د بیاکتنې پوښتنې په توګه ولولئ. هغه مخکښه نقشه چې پر کاغذ اجازه لري خو پر هغه اړیکه تنظیم شوې چې تاسو یې مالک نه یاست، لا هم بند پاتې پروژه ده، او هغه PAT قاعده چې ترافیک تېروي خو د هر پیرودونکي لاګینګ ماتوي، په راتلونکې پلټنه کې ناکامېږي.
له ژمنې مخکې نقشه کول تایید کړئ
له لارې یو نوی اپلیکیشن عملیات ولېږئ او یوازې غوښتنه نه، ځواب هم تایید کړئ. د backend له مالک څخه وپوښتئ چې د هغوی لاګونو کومه سرچینه پته ثبت کړه، وګورئ چې په دواړو لورو کې د پتو کورنۍ چلند له پلان سره سمون خوري، او تایید کړئ چې هغه لار چې باید رد شي لا هم ردېږي. زړه اړیکه د هغې نقشې په اړه هېڅ نه ثبوتوي چې همدا اوس مو بدله کړه.
د backend تصدیق له دې خپلواک وساتئ چې کومه ژباړل شوې پته د هغه اجازه لیست پوره کوي، ځکه نقشه کول د شبکې پلمبرۍ دي نه د لاسرسي کنټرول پرېکړه. هغه شیبه چې د پټنوم بیا تنظیمول د NAT مخکښ پورې تړلي شي، هر راتلونکی د ساحې بدلون خنډ ته اوړي.
له تصویب مخکې درې ځوابونه ولیکئ: د ژباړې ډول، د ژباړونکي مالک، او هغه ملاتړ شوې اړیکه یا محصول لار چې هغه ږدي. که له دوی څخه یو هم لا اټکل وي، ډیزاین د بدلون کړکۍ لپاره چمتو نه دی.