AWS Site-to-Site VPN سے NAT Gateway تک: VGW بمقابلہ Transit Gateway

پہلی بار سب وہی خاکہ بناتے ہیں: VPC میں VPN، پھر NAT gateway سے انٹرنیٹ تک، ہو گیا۔ لیکن جب VPN کسی virtual private gateway پر ختم ہوتا ہے تو AWS اس راستے کی حمایت نہیں کرتا، اور ناکامی اتنی خاموش ہے کہ ٹیمیں اسے ایک سے زیادہ بار دوبارہ بناتی ہیں۔ کام کرنے والے ڈیزائن کو transit gateway درکار ہے، جو دونوں طرف gateway اور route tables بدلتا ہے۔ کچھ بنانے سے پہلے دونوں شکلوں کا موازنہ کریں۔

وہ ٹوپولوجی جو واضح دکھتی ہے اور معاون نہیں

AWS کی NAT gateway دستاویز ایسی لکیر کھینچتی ہے جو ہر اس شخص کو حیران کرتی ہے جس نے صرف ایک VPC کے ڈیزائن بنائے ہیں: Site-to-Site VPN کنکشن کا ٹریفک virtual private gateway کے ذریعے NAT gateway تک روٹ نہیں کیا جا سکتا۔ VPN جس قسم کے gateway پر ختم ہوتا ہے وہی طے کرتا ہے کہ ترجمے کا راستہ ہے بھی یا نہیں۔ غلطی اس لیے باقی رہتی ہے کہ ٹنل کی حالت UP ہے اور اسی subnet کا EC2 instance بغیر مشکل انٹرنیٹ تک پہنچتا ہے۔ ان دونوں مشاہدوں میں سے کوئی بھی ٹوٹی ہوئی سمت جانچتا نہیں۔

عملاً پیکٹ آن-پریمائسز نیٹ ورک کے ماخذ پتے کے ساتھ آتا ہے اور اسے ترجمہ کرنے والا کوئی معاون اگلا hop نہیں ملتا۔ جدولوں کے مطابق اسے egress حد پر گرا دیا جاتا ہے، اور چونکہ ٹنل UP رہتی ہے جبکہ اسی subnet کا instance انٹرنیٹ تک پہنچتا ہے، ناکامی کو آن-پریمائسز firewall مسئلہ قرار دیا جاتا ہے۔

Virtual private gateway بمقابلہ transit gateway

ایک virtual private gateway ایک ہی VPC کا ہوتا ہے۔ یہ VPN ختم کرتا ہے، اس VPC کی route tables میں routes رکھتا ہے اور وہیں رک جاتا ہے۔ اس میں attachment ماڈل نہیں، اس لیے یہ دوسرے VPC یا مشترکہ egress حصے کو ٹریفک نہیں دے سکتا۔ یہی واحد-VPC دائرہ پوری حد ہے، اور VPC کے اندر شامل کیا گیا کوئی route اسے نہیں بدلتا۔

Transit gateway ایک علاقائی مرکز ہے جہاں VPN، ہر spoke VPC اور مشترکہ سروسز کا VPC سب attachments کے طور پر نظر آتے ہیں۔ اس کی اپنی route tables ہیں جو طے کرتی ہیں کہ کون سا attachment کوئی دیا گیا prefix لے گا۔

یہی مرکز مرکزی egress کو ممکن بناتا ہے: VPN ایک attachment کے طور پر اترتا ہے، egress VPC دوسرے کے طور پر، اور transit gateway کی route table انٹرنیٹ کی طرف کے prefixes پہلے سے دوسرے تک بھیجتی ہے۔ virtual private gateway کے ساتھ بھیجنے کے لیے دوسرا attachment نہیں ہوتا، اسی لیے ڈیزائن بعد میں پیچ کر کے نہیں بنایا جا سکتا۔

معاون egress راستہ، قدم بہ قدم

حوالہ جاتی ڈیزائن میں پانچ hops ہیں اور ہر تیر ایک route فیصلہ ہے جو آپ کو تشکیل دینا ہے۔ ٹریفک آن-پریمائسز نیٹ ورک سے Site-to-Site VPN attachment میں جاتا ہے، transit gateway کی route table اسے egress VPC attachment کی طرف بھیجتی ہے، جہاں subnet جدول اسے عوامی NAT gateway پر بھیجتی ہے۔ NAT gateway ماخذ کا ترجمہ کرتا ہے اور internet gateway پیکٹ باہر لے جاتا ہے۔

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

آخری hops کام کریں گے یا نہیں یہ دو باتیں طے کرتی ہیں۔ NAT gateway عوامی ہونا چاہیے، elastic IP اور internet gateway کی طرف route کے ساتھ، کیونکہ نجی NAT gateway نیٹ ورکس کے درمیان ترجمہ کرتا ہے اور کبھی انٹرنیٹ اخراج نہیں بنتا۔

آپ جس بھی Availability Zone کو خدمت دینا چاہتے ہیں اس کے لیے ایک NAT gateway کی منصوبہ بندی کریں، اور ہر subnet جدول مقامی کی طرف اشارہ کرے۔ اپنے نوٹس میں transit gateway کی جدول اور VPC کی جدولیں الگ اشیاء کے طور پر رکھیں، کیونکہ ایک attachment چنتی ہے اور دوسری VPC کے اندر کا وسیلہ۔ صرف ایک میں default route ہونے سے آدھا راستہ غیر واضح رہتا ہے اور وہ جزوی ناکامیاں پیدا ہوتی ہیں جنہیں جوڑنا سب سے مشکل ہے۔

یہ ڈیزائن واپسی کے راستے ہی پر ناکام ہوتے ہیں

NAT gateway پہلے دیکھے گئے flows کے لیے stateful ہے، اس لیے باہر جانے والے کنکشن کے جواب نئے inbound اصول کے بغیر واپس آتے ہیں۔ یہ خاصیت کسی مقامی سروس کو انٹرنیٹ پر شائع نہیں کرتی، اور ایسا سمجھنا کہ کرتی ہے، ٹیم کو ایسے کنکشن کو ڈیبگ کرنے میں دن گزارنے پر مجبور کرتا ہے جو کبھی بننا ہی نہیں تھا۔ کلائنٹ سے شروع ہونے والے ٹریفک کے لیے چار routes کا متفق ہونا ضروری ہے: آن-پریمائسز پالیسی، transit gateway کی جدول، egress subnet جدول اور NAT subnet جدول۔ آخری رہ گیا تو درخواست عمارت چھوڑ دیتی ہے جبکہ جواب AWS کے اندر مر جاتا ہے۔

VPN کے پیچھے حقیقی کلائنٹ سے تصدیق کریں اور دیکھیں کہ وہ کون سا عوامی ماخذ پتہ پیش کرتا ہے۔ اگر وہ NAT gateway کا elastic IP ہے تو ترجمہ ہو رہا ہے؛ اگر کچھ اور ہے تو آپ دوسرا egress ناپ رہے ہیں۔

اس ناکامی کی غیر متناسب شکل کو جلد پہچاننا چاہیے۔ جب ایک Availability Zone کی NAT subnet جدول میں کلائنٹ prefix کی طرف واپسی route ہے اور دوسری میں نہیں، تو نئے کنکشن flow کس زون میں گرتا ہے اس کے مطابق کامیاب یا ناکام ہوتے ہیں، اور اس نمونے کو غلطی سے غیر مستحکم انٹرنیٹ پڑھا جاتا ہے۔ ٹکٹ کھلنے والے زون کو ٹھیک کرنے کے بجائے آپ جن زونوں کو خدمت دیتے ہیں ان کی subnet جدولیں موازنہ کریں، کیونکہ غائب route ہی پورا نقص ہے اور دوسری طرف کچھ بدلنے کی ضرورت نہیں۔

کب واضح proxy بہتر ڈیزائن ہے

egress VPC کے instance پر HTTP proxy جائز متبادل ہے اور اکثر سستا بھی۔ کلائنٹ اسے استعمال کرنے کے لیے تشکیل دیے جاتے ہیں، proxy اپنا کنکشن باہر کھولتا ہے، اور واپسی کا راستہ متوازی routing کی پہیلی نہیں بلکہ proxy کا مسئلہ بن جاتا ہے۔ چند ایپلیکیشنز کے لیے یہ transit gateway کا بیشتر کام ہٹا دیتا ہے۔ یہ فی صارف لاگنگ بھی دیتا ہے جو NAT gateway نہیں بنا سکتا۔

تاہم یہ شفاف نہیں۔ proxy کی ترتیبات نظر انداز کرنے والی ہر چیز، اور HTTP کے علاوہ ہر پروٹوکول، اس راستے پر نہیں جائیں گے۔

انتخاب اس پر ہے کہ آپ کی ایپلیکیشنز واقعی کیا بولتی ہیں اور لاگز میں کتنی شناخت درکار ہے۔ جہاں وہ HTTP بولتی ہیں وہاں proxy اپنی جگہ کماتا ہے؛ جہاں من مانی پروٹوکولز کے لیے عمومی egress درکار ہو وہاں AWS کا معاون ڈیزائن transit gateway ہے۔ یہ پہلے سے طے کرنا route tables بننے کے بعد دریافت کرنے سے سستا ہے۔