آپ VPC کنسول کھولتے ہیں کیونکہ ایک پارٹنر نے پوچھا کہ سائٹ ٹو سائٹ VPN کے ذریعے کون سی ماخذ رینج آئے گی۔ NAT گیٹ ویز صفحہ Elastic IP کے ساتھ منسلک عوامی گیٹ وے دکھاتا ہے، اور لالچ یہ ہے کہ وہی پتہ بھیج کر آگے بڑھ جائیں۔ انٹرنیٹ راستے کے لیے یہ درست جواب ہے اور VPN راستے کے لیے غلط جواب، اور فرق یہ ہے کہ روٹ ٹیبل کس گیٹ وے کی طرف اشارہ کرتی ہے۔ اجازت فہرست لکھنے سے پہلے راستہ چل کر دیکھیں۔

اجازت فہرست سے نہیں، NAT گیٹ ویز صفحے سے شروع کریں

NAT گیٹ ویز صفحہ آپ کو سب نیٹ، قسم اور Elastic IP بتاتا ہے، اور یہ تین فیلڈز شروع کرنے کے لیے کافی ہیں۔ جو یہ نہیں بتاتا وہ ہے وہ راستہ جو ٹریفک بعد میں لیتا ہے۔ یہ NAT گیٹ وے کے سب نیٹ سے منسلک روٹ ٹیبلز سے آتا ہے۔

پہلے قسم پڑھیں، کیونکہ عوامی یا نجی ہونا طے کرتا ہے کہ زنجیر میں بعد میں انٹرنیٹ گیٹ وے آئے گا یا نہیں۔ پھر سب نیٹ پڑھیں، کیونکہ دوسرا راستہ وہیں ہے۔

دونوں تبدیلیوں کی پیروی کریں

عوامی اور نجی دونوں NAT گیٹ وے ورک لوڈ کے نجی IPv4 ماخذ کو NAT گیٹ وے کے اپنے نجی IPv4 پتے میں بدلتے ہیں۔ یہ پہلی تبدیلی قسم سے قطع نظر ہوتی ہے۔ دوسری تبدیلی وہ ہے جو لوگ بھول جاتے ہیں: عوامی NAT گیٹ وے ٹریفک انٹرنیٹ گیٹ وے کے حوالے کرتا ہے، جو پتے کو منسلک Elastic IP پر نقش کرتا ہے۔

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

نجی راستے میں زنجیر میں کوئی انٹرنیٹ گیٹ وے نہیں ہوتا۔ جب ٹریفک ٹرانزٹ گیٹ وے یا مجازی نجی گیٹ وے سے باہر جاتا ہے، تو NAT گیٹ ویز گائیڈ NAT گیٹ وے کے نجی پتے کو اس ماخذ کے طور پر درج کرتا ہے جو دور دراز فریق وصول کرتا ہے۔ پارٹنر کو یہی پتہ اجازت دینا چاہیے، Elastic IP نہیں۔

VPN راستہ عام طور پر نجی پتہ دکھاتا ہے

10.20.1.0/24 میں موجود ورک لوڈ کے لیے جو پارٹنر کے سابقے تک پہنچتا ہے، ورک لوڈ سب نیٹ کی روٹ ٹیبل NAT گیٹ وے کی طرف اور NAT گیٹ وے کے سب نیٹ کی روٹ ٹیبل نجی گیٹ وے کے راستے کی طرف اشارہ کرتی ہے۔ دونوں چھلانگیں اہم ہیں، اور صرف دوسری طے کرتی ہے کہ پارٹنر کیا دیکھتا ہے۔ اگر NAT سب نیٹ کے پاس VPN راستے تک کوئی روٹ نہ ہو، تو پیکٹ کبھی نہیں پہنچتا، اور یہ غلط ماخذ پتے سے مختلف ناکامی ہے۔

پتوں کی بات کرنے سے پہلے ہی وہ دوسرا راستہ تصدیق کریں۔ غیر موجود روٹ اور غلط بتایا گیا ماخذ ٹریفک نہ دیکھنے والے پارٹنر کو بالکل یکساں دکھتے ہیں۔

جب دوسری تبدیلی جواب بدل دیتی ہے

AWS ٹرانزٹ گیٹ وے اٹیچمنٹ پر ایک واضح، مماثل ایک سے ایک NAT نقشہ بندی بھی پیش کرتا ہے۔ یہ نقشہ بندی دور دراز سروس کے دیکھنے سے پہلے ماخذ کو دوبارہ بدل سکتی ہے، اور یہ صرف روٹ کرنے والا طے شدہ رویہ نہیں ہے۔ چونکہ اسے جان بوجھ کر تشکیل دینا پڑتا ہے، اسے ڈیزائن کی استثنا سمجھیں، نہ کہ ایسی چیز جو اتفاقاً ورثے میں ملے۔ اگر آپ کی ٹیم میں کسی کو یاد نہیں کہ اسے آن کیا گیا تھا، تو اٹیچمنٹ پڑھنے تک اسے غیر موجود مانیں۔

اگر آپ کا ڈیزائن اسے استعمال کرتا ہے، تو اجازت فہرست کو NAT گیٹ وے کا پتہ نہیں بلکہ حتمی نقشہ بندی بیان کرنی چاہیے۔ یہی احتیاط دستیابی کے راستوں پر بھی لاگو ہوتی ہے: جب کئی گیٹ وے پتے حصہ لیں تو متوقع ماخذ مجموعہ اتحاد ہوتا ہے، کوئی ایک نمائندہ پتہ نہیں۔ لکھیں کہ ہر پتہ کس تبدیلی کا ہے، کیونکہ بغیر اصل کی فہرست کا بعد میں آڈٹ کرنا ناممکن ہے۔

نجی NAT گیٹ وے کو انٹرنیٹ گیٹ وے کی طرف اشارہ کر کے انٹرنیٹ سروس نہیں دی جا سکتی؛ AWS درج کرتا ہے کہ ایسی ٹریفک پھینک دی جاتی ہے۔ قسم پورے راستے سے چنیں، تقاضے کے VPN لفظ سے نہیں۔

وہ معاہدہ لکھیں جس پر آپ کا پارٹنر عمل کر سکے

قابل استعمال معاہدے کے چار حصے ہیں: وہ سمت جہاں سے بہاؤ شروع ہوتے ہیں، وہ تبدیل شدہ شناخت جو پارٹنر دیکھے گا، اس شناخت کے لیے واپسی کا راستہ، اور لاگو ہونے والا تحفظ دائرہ۔ NAT گیٹ وے کے بہاؤ معاون ماخذ طرف سے شروع ہوتے ہیں، اس لیے یہ نجی ورک لوڈ کو بے نقاب کرنے کے لیے آنے والی پورٹ فارورڈنگ سروس نہیں ہے۔ یہ بات بروقت بلند آواز میں کہنے سے ایسا ڈیزائن جائزہ رک جاتا ہے جس میں ہر فریق سمجھ رہا تھا کہ دوسرا فریق شروع کر رہا ہے۔

تبدیلی پتوں کے باہمی اوورلیپ سے راحت اور پیش گوئی کے قابل ماخذ پالیسی خریدتی ہے، اور پارٹنر کے لاگز میں انفرادی ورک لوڈ شناخت آپ کو گنوا دیتی ہے۔ اگر آڈٹ کو ہر ورک لوڈ کے لیے انتساب چاہیے، تو وہ شناخت تبدیل شدہ ماخذ پتے سے بحال کرنے کی کوشش کے بجائے ایپلیکیشن پرت پر رکھیں۔

پھر کسی بھی تبدیلی کے بعد دونوں روٹ ٹیبلز دوبارہ جانچیں، کیونکہ نیا اٹیچمنٹ یا دوبارہ منسلک سب نیٹ جواب خاموشی سے دوبارہ لکھتا ہے۔

متعلقہ مضامین