NAT ٹریورسل ESP کو UDP کے اندر کیسے لپیٹتا ہے

ایک ہی روٹر کے پیچھے دو کلائنٹ ایک IPsec گیٹ وے سے بات کرتے ہیں، اور ایک مسلسل گرتا رہتا ہے جبکہ دوسرا جڑا رہتا ہے۔ اصلی ESP ایک ایسا IP پروٹوکول 50 ہے جس میں پورٹس نہیں ہوتے، اس لیے جب کئی کلائنٹ ایک ہی پتہ شیئر کرتے ہیں تو مترجم کے پاس میپنگ کے لیے پکڑنے کو کچھ نہیں ہوتا۔ NAT ٹریورسل 4500 پر ESP کو UDP کے اندر لپیٹ کر یہ خلا بھرتا ہے، اور وہ ہیڈر بعد کے بیشتر علامات کی وضاحت کرتا ہے۔ یہ اس ڈیوائس کی طرف بھی اشارہ کرتا ہے جسے بدلنا ہے۔

ڈیٹا طیارہ 4500 پورٹ پر کیوں جاتا ہے

سیٹ اپ کے دوران IKEv2 ہر فریق کے استعمال کردہ سمجھے جانے والے پتوں اور پورٹس کا موازنہ کرتا ہے، اپنی NAT شناخت اطلاعات میں ہیش کا تبادلہ کر کے۔ جب ہیش نہیں ملتے تو راستے میں کہیں ایک مترجم بیٹھا ہوتا ہے، اور دونوں فریق محفوظ ٹریفک کو UDP انکیپسولیشن پر منتقل کر دیتے ہیں۔ اسی لیے مترجم سے سامنا کرنے والا سیشن نہ کرنے والے سے مختلف دکھائی دیتا ہے۔

لپیٹنا ایک لفافہ ہے، پروٹوکول کی تبدیلی نہیں: ESP اپنا ہیڈر، سالمیت کی جانچ اور خفیہ کاری برقرار رکھتا ہے، اور UDP صرف وہ پورٹس فراہم کرتا ہے جن کی مترجم کو ضرورت ہے۔ پورٹ 500 IKE تبادلہ اٹھاتا ہے؛ 4500 شناخت کے بعد لپیٹا گیا ڈیٹا، اور اکثر بعد کے IKE پیغامات بھی اٹھاتا ہے۔ کوئی بھی پورٹ بہاؤ کو TCP کنکشن نہیں بناتا، یہی مفروضہ کیپچر پڑھنے والے بیشتر لوگوں کو گمراہ کرتا ہے۔

دونوں مراحل ترتیب سے جانچیں

پہلے کنٹرول تبادلے کو، پھر ڈیٹا راستے کو ثابت کریں، اور دونوں کو اپنے نوٹس میں الگ رکھیں۔ وہ کیپچر جو 500 پر ٹریفک دکھائے اور 4500 پر کبھی نہ دکھائے، عام طور پر اس کا مطلب ہے کہ ڈیٹا راستہ فلٹر ہو رہا ہے، اس لیے اصلاح کلائنٹ میں نہیں، فائر وال قاعدے میں کرنی ہے۔

tcpdump -ni any 'udp port 500 or udp port 4500' کے ساتھ دونوں پورٹس دیکھیں، اور سیشن فعال رہنے کے دوران روٹر پر ترجمے کا جدول پڑھیں۔ وہ جدول وہ ماخذ پورٹ دکھاتا ہے جو گیٹ وے واقعی دیکھے گا، اور لیپ ٹاپ پر کیپچر بناوٹی طور پر اس سے مختلف ہے: لیپ ٹاپ 500 مانتا ہے جبکہ گیٹ وے ترجمہ شدہ ماخذ پورٹ کے ساتھ 4500 دیکھتا ہے، اور دونوں درست ہیں۔ وہی بہاؤ، ترجمے سے پہلے اور بعد:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

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

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

ایک وقت میں دو کلائنٹ کے لیے میپنگ کا جدول پڑھیں: اگر دونوں ایک ہی ترجمہ شدہ پورٹ دکھائیں تو ڈیوائس انہیں ویسے الگ نہیں کر رہی جیسے گیٹ وے چاہتا ہے۔ جو پاس تھرو موڈ صرف ایک ہوسٹ کو اصلی ESP دیتا ہے وہ کئی ترجمہ شدہ کلائنٹ کی خدمت کے برابر نہیں، حالانکہ بیچنے والے دونوں کو IPsec کے لیے دوستانہ بتاتے ہیں۔ دوہرا NAT میپنگ کی ایک پرت اور ایک اور ختم ہونے کا مقام جوڑتا ہے، لیکن باہر جانے والے کنکشن خود بخود نہیں توڑتا۔

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

میپنگ کا مالک بدلیں، پھر دوبارہ جانچیں

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

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