Anypoint VPN یا Transit Gateway NAT: ترجمہ کہاں ہوتا ہے
Anypoint VPN خود پتوں کا ترجمہ نہیں کرتا۔ NAT کا وعدہ کرنے سے پہلے فائر وال PAT، AWS پری فکس نقشہ یا کسی اور کنکشن میں سے انتخاب کریں۔
NAT کی ضرورت تب تک ضرورت نہیں جب تک وہ بدلتے ہوئے پتوں اور اُنہیں بدلنے کی اجازت رکھنے والے جزو کا نام نہ لے۔ MuleSoft کنیکٹیویٹی میں اُس فیصلے کے تین اِن پٹ ہیں: بیک اینڈ کو کئی-سے-ایک پورٹ ترجمہ چاہیے یا ایک-سے-ایک پری فکس عرف، آپ کے اصل ملکیت والا AWS کنکشن وہ میپنگ کر سکتا ہے یا نہیں، اور کیا پورا راستہ وینڈر کے تعاون یافتہ امتزاج میں رہتا ہے۔ یہ غلط ہوئے تو آپ کام کرنے والی مگر جائزے میں ناکام ہونے والی لیب بنائیں گے۔
ایک ہی مستقل نکتہ یہ ہے کہ Anypoint VPN خود ترجمے کا آلہ نہیں ہے۔ CloudHub 2.0 کی دستاویز وہاں NAT کو غیر تعاون یافتہ کے طور پر درج کرتی ہے، اس لیے کوئی بھی ڈیزائن جو یہ فرض کرے کہ ٹنل آپ کے ورکرز کے پتے چھپا دے گا، پہلے ہی ٹوٹا ہوا ہے۔
طے کریں کہ ترجمے کو کیا کرنا ہے
اگر بہت سے ایپلیکیشن ورکرز بیک اینڈ کے سامنے ایک ہی پتے کے طور پر نظر آنے چاہئیں، تو ضرورت مشترکہ ماخذ ترجمہ ہے، عام طور پر اُس فائر وال پر حالت برقرار رکھنے والا SNAT یا PAT جسے آپ کنٹرول کرتے ہیں۔ اُس جزو کو منظور شدہ راستے پر بیٹھنا چاہیے، پورے فلو کی زندگی اپنی حالت برقرار رکھنی چاہیے اور ہر اُس کنکشن کی واپسی ٹریفک دیکھنی چاہیے جسے اس نے دوبارہ لکھا۔ سیشن کے درمیان حالت کھونا کنکشن کو کمزور نہیں کرتا؛ یہ اُسے ختم کر دیتا ہے۔ حالت شیئر کرنے سے انکار کرنے والی فائر وال جوڑی فیل اوور کے بعد اسٹینڈ بائی ممبر پر آنے والا ہر سیشن گرا دے گی۔ اُس جزو کی پیمائش بیک وقت چلنے والے فلو کے لیے کریں، تھرو پٹ کے لیے نہیں۔
اگر اِس کے بجائے دو نیٹ ورک اوور لیپ ہوں اور ہر ہوسٹ کو الگ عرف درکار ہو، تو ضرورت واضح طور پر میپ شدہ پری فکس، موافق راستے اور میپنگ سے متفق نام حل کے ساتھ ایک-سے-ایک پتہ منصوبہ ہے۔ ہر ورکر کو ایک پتے کے پیچھے چھپانا اُس کا سستا نسخہ نہیں ہے، اور ڈیزائن جائزے میں ایک کو دوسرے سے بدلنا ہی وہ طریقہ ہے جس سے منصوبے ایک سہ ماہی کھو دیتے ہیں۔
پروڈکٹ چننے سے پہلے فیصلہ ٹھوس الفاظ میں درج کریں: اصل ماخذ، اصل منزل، مترجم قدر، آغاز کی سمت، مترجم کا مالک اور متوقع جوابی راستہ۔ یہ بھی شامل کریں کہ بیک اینڈ لاگز کون سی شناخت رکھیں گے، کیونکہ تمام ماخذ چھپانے والا ڈیزائن ہر کلائنٹ کے آڈٹ کو بھی تباہ کرتا ہے۔
دیکھیں کہ 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، ترجمہ اور روٹنگ ماڈل استعمال کریں۔ بیک اینڈ کا جواب اُسی ترجمہ جزو سے واپس آنا چاہیے، اور صحت مند آؤٹ باؤنڈ ٹنل اُس واپسی راستے کے بارے میں کچھ نہیں کہتا۔
ٹرانزٹ گیٹ وے راستے کے لیے، نجی جگہ کنکشن، متعلقہ روٹ جدول، مقامی کنکشن اور وہ حصے فہرست کریں جنہیں گاہک واقعی ترتیب دے سکتا ہے۔ یہ مختلف کنیکٹیویٹی معماری ہے، موجودہ Anypoint VPN کنکشن پر لگایا گیا NAT چیک باکس نہیں، اور معاونت کی حد اِس کے ساتھ سرکتی ہے۔
تین آپشنز کا ایک ہی جدول میں موازنہ کریں
زیادہ تر ٹیمیں صرف دو سوالوں کے جواب دیتی ہیں: کئی-سے-ایک یا ایک-سے-ایک، اور کنکشن کا مالک کون ہے۔ نیچے دیا گیا جدول اُن جوابات کو ابتدائی آپشن میں بدل دیتا ہے۔
| 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 قاعدہ اگلے آڈٹ میں ناکام ہوتا ہے۔
وعدہ کرنے سے پہلے میپنگ کی تصدیق کریں
راستے سے ایک نیا ایپلیکیشن عمل گزاریں اور صرف درخواست نہیں بلکہ جواب کی بھی تصدیق کریں۔ بیک اینڈ کے مالک سے پوچھیں کہ اُن کے لاگز نے کون سا ماخذ پتہ درج کیا، دونوں سمتوں میں پتہ خاندان کی کارروائی منصوبے سے میل کھاتی ہے یا نہیں جانچیں، اور تصدیق کریں کہ جس راستے کو مسترد ہونا چاہیے وہ اب بھی مسترد ہوتا ہے۔ پرانا کنکشن اُس میپنگ کے بارے میں کچھ ثابت نہیں کرتا جو آپ نے ابھی بدلی۔
بیک اینڈ کی توثیق کو اِس بات سے آزاد رکھیں کہ کون سا مترجم پتہ اُس کی اجازت فہرست پورا کرتا ہے، کیونکہ میپنگ نیٹ ورک کی پلمبنگ ہے، رسائی کنٹرول کا فیصلہ نہیں۔ جس لمحے پاس ورڈ ری سیٹ NAT پری فکس پر منحصر ہو، اُس لمحے سے ہر آئندہ رینج تبدیلی خلل بن جاتی ہے۔
منظوری سے پہلے تین جواب لکھیں: ترجمے کی قسم، مترجم کا مالک، اور وہ تعاون یافتہ کنکشن یا پروڈکٹ راستہ جو اِسے اٹھاتا ہے۔ اگر اِن میں سے کوئی بھی اب بھی اندازہ ہو، تو ڈیزائن تبدیلی ونڈو کے لیے تیار نہیں۔