AWS NAT گیٹ وے سے GRE اور ESP کیوں ناکام ہوتے ہیں

ٹنل ناکام ہوتا ہے، سیکیورٹی گروپ پہلے ہی تمام ٹریفک کی اجازت دیتا ہے، اور نتیجہ یہ نکالا جاتا ہے کہ AWS VPN کو بلاک کر رہا ہے۔ یہ کچھ بھی بلاک نہیں کر رہا۔ منظم NAT گیٹ وے بیرونی پروٹوکولز کا ایک دستاویزی مجموعہ آگے بھیجتا ہے، اور مقامی GRE یا مقامی ESP اس میں نہیں ہیں، اس لیے آپ کا شامل کردہ کوئی قاعدہ گیٹ وے کو انہیں لے جانے پر مجبور نہیں کرے گا۔ اجازت کا قاعدہ اور منتقلی کی صلاحیت دو مختلف چیزیں ہیں، اور ان میں سے صرف ایک آپ کے بدلنے کے اختیار میں ہے۔

قواعد کا مجموعہ پروٹوکولز کا مجموعہ نہیں ہے

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

AWS کی NAT گیٹ وے پروٹوکول تفصیل منظم سروس کے لیے TCP، UDP اور ICMP کی فہرست دیتی ہے۔ یہی پورا معاون مجموعہ ہے۔ کسی دوسرے IP پروٹوکول کے لیے اجازت کا قاعدہ اسے بڑھا نہیں سکتا، کیونکہ قاعدہ گیٹ وے کے آگے بھیجنے کے راستے تک پہنچنے سے بہت پہلے جانچا جاتا ہے۔

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

PPTP بتاتا ہے کہ پورٹ ٹیسٹ کیوں جھوٹ بولتا ہے

کچھ بھی ثابت نہ کرنے والی پورٹ جانچ کی سب سے واضح پرانی مثال PPTP ہے۔ یہ پورٹ 1723 پر TCP کنٹرول کنکشن کھولتا ہے اور پھر ٹنل ڈیٹا GRE پر لے جاتا ہے، جو IP پروٹوکول 47 ہے۔ پروٹوکول 47 TCP پورٹ 47 نہیں ہے، اور ان دو نمبروں کا ایک دوسرے سے کوئی تعلق نہیں سوائے ہندسے بانٹنے کے۔

جو آپریٹر 1723 سے رابطہ جانچتا ہے اور مکمل ہاتھ ملانا دیکھتا ہے وہ نتیجہ نکالتا ہے کہ راستہ کام کر رہا ہے۔ پھر ڈیٹا چینل کبھی ایک بھی پیکٹ نہیں گزارتا، کیونکہ گیٹ وے کے پاس دینے کے لیے کوئی GRE معاونت نہیں ہے۔ یہ پرانے پروٹوکول کی ضروریات کی تشریح ہے، PPTP تعینات کرنے کا مشورہ نہیں، جو برسوں سے متروک ہے۔

یہی استدلال ہر ایسے پروٹوکول پر لاگو ہے جس کا کنٹرول چینل TCP یا UDP ہو جبکہ اس کا ڈیٹا راستہ ایسا نہ ہو۔

IPsec صرف UDP کے طور پر زندہ رہتا ہے

IPsec وہ معاملہ ہے جہاں جواب سیدھا نہیں بلکہ مشروط ہے۔ AWS NAT گیٹ وے کے ذریعے IPsec کے لیے NAT ٹراورسل کو معاون انتظام کے طور پر دستاویز کرتا ہے۔ NAT-T پر بات چیت ہونے کے بعد ESP کو UDP کے اندر سمویا جاتا ہے اور گیٹ وے پروٹوکول 50 کی بجائے عام UDP دیکھتا ہے۔

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

TCP یا UDP پر مبنی VPN دستاویزی منتقلی مجموعے میں فٹ بیٹھتا ہے اور پھر بھی روٹنگ، فلٹرنگ یا تصدیق کی وجوہات سے ناکام ہو سکتا ہے۔ مجموعے میں فٹ بیٹھنا ضروری ہے، کافی نہیں۔

پالیسی بڑھانے سے پہلے راستہ جانچیں

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

پھر آزمایا گیا اینڈ پوائنٹ، پتہ خاندان، بیرونی پروٹوکول اور پورٹ جہاں پروٹوکول کے پاس ہو، درج کریں۔ کامیاب براؤزر درخواست کی بجائے کلائنٹ کی تشخیص اور نیٹ ورک مالک کے بہاؤ مشاہدات استعمال کریں، کیونکہ یہ صرف یہ ثابت کرتا ہے کہ TCP اور UDP کام کرتے ہیں۔ اس کے بعد، بہاؤ کی دونوں سمتوں کے لیے سیکیورٹی گروپ، سب نیٹ ACL، مہمان فائر وال اور سروس پالیسی کا جائزہ لیں۔

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

جب منتقلی فٹ نہ بیٹھے

اگر بیرونی پروٹوکول معاون مجموعے سے باہر ہے تو حل معماری ہے: ایسی منتقلی چنیں جو راستہ لے جا سکے، یا اخراج کو کسی ایسی چیز پر منتقل کریں جو آپ کو درکار چیز لے جائے۔ OpenVPN UDP پر، WireGuard UDP پر اور TLS پر مبنی ٹنل سب دستاویزی مجموعے میں فٹ بیٹھتے ہیں۔ گاہک کے زیرِ انتظام NAT انسٹانس اس وقت آپشن ہے جب کوئی مخصوص پروٹوکول گزرنا ضروری ہو اور اسے چلانے کی آپریشنل لاگت قابلِ قبول ہو۔

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

کام کی ترتیب: بیرونی پروٹوکول کا نام لیں، اگلے ہاپ کی تصدیق کریں، دستاویزی مجموعے سے موازنہ کریں، پھر معماری یا منتقلی بدلیں۔ مختلف پورٹ نمبر GRE کو TCP نہیں بنا سکتا، اور ایک اور اجازت دینے والا قاعدہ مکمل کنٹرول تبادلے کو کام کرنے والا ڈیٹا چینل نہیں بنا سکتا۔