L2TP، GRE یا IPsec: سیشن کو کون سی تہہ اٹھانا چاہیے؟

ایک ہی ڈیزائن نوٹ میں L2TP، GRE اور IPsec کے اکٹھے آنے پر دو سوال الجھ جاتے ہیں: میں کون سا سیشن اٹھا رہا ہوں، اور اسے کون سی تہہ محفوظ کرتی ہے؟ پہلا غلط ہو تو نیچے کا سب کچھ اندرونی طور پر درست رہتا ہے مگر غلط مسئلہ حل کرتا ہے — ایسی جگہ بنایا گیا روٹ شدہ اوورلے جہاں صارفین کو ڈائل اِن کرنا تھا، یا سائٹ ٹو سائٹ گیٹ وے کی جگہ کھڑا ڈائل اِن مرکز۔ نیچے دیا گیا ورک شیٹ کسی کے بھی آلے میں لاگ اِن کرنے سے پہلے یہ فرق لازم کر دیتا ہے۔ اسے ترتیب سے بھریں اور ہر سطر ایسی چیز بن جاتی ہے جسے آپ خود جانچ سکتے ہیں۔

پروٹوکول فہرست سے نہیں، سیشن سے شروع کریں

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

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

ہر تہہ کو بالکل ایک کام دیں

L2TPv2 اپنے دو آخری نقاط کے درمیان PPP سیشن اٹھاتا ہے۔ PPP لنک کی گفت و شنید اور، جب اس پر بات ہو جائے، صارف کی تصدیق چلاتا ہے؛ L2TP کوئی خفیہ نگاری شامل نہیں کرتا، اس لیے محض L2TP ڈیمون IPsec کے سلامتی رشتے کا کوئی حصہ نافذ نہیں کرتا اور صرف ایسے لنک کے اندر رہتا ہے جس پر آپ پہلے ہی بھروسا کرتے ہیں۔

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

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

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

ایک پیکٹ لیں اور شامل ہونے والا ہر سرنامہ شامل ہونے کی ترتیب سے گنوائیں، اور اسے شامل کرنے والا آلہ بتائیں۔ ڈائل اِن صارف کے لیے یہ عموماً IPsec کے اندر L2TP کے اندر PPP ہوتا ہے؛ سائٹ اوورلے کے لیے یہ IPsec کے اندر GRE کے اندر اندرونی IP پیکٹ ہوتا ہے۔ اگر دو آلے ایک ہی سرنامہ شامل کریں تو آپ کے پاس لوپ یا دہرا سرنگ ہے، اور پالیسی کی کوئی تدوین اسے درست نہیں کرے گی۔

وہی فہرست MTU طے کرتی ہے، کیونکہ قابل استعمال اندرونی حجم ماپے گئے راستے کا MTU ہے جس سے ابھی گنوائے گئے سرنامے منہا کیے گئے ہوں اور کچھ نہیں۔ فورم کی تحریر سے عدد نقل نہ کریں: بیرونی IP، UDP اور ESP کا اخراج، پھر GRE یا L2TP، پھر جہاں لاگو ہو PPP جمع کریں، اور اُس راستے کے MTU سے منہا کریں جو آپ نے واقعی ماپا۔ صرف بڑی منتقلیوں پر ظاہر ہونے والی علامات، یا قائم ہو کر پہلے بڑے جواب پر مر جانے والے سیشن، عموماً اسی طرف لوٹتے ہیں کہ وہ جمع اندازے سے کیا گیا۔

ہر تہہ کو الگ الگ، باہر سے اندر جانچیں

جانچیں ترتیب سے چلائیں اور پہلی ناکام پر رک جائیں۔ ہر سطر مختلف سوال کا جواب دیتی ہے، اس لیے ناکامی سرنگ ٹوٹنے کہنے کی بجائے ورک شیٹ کے ایک ستون کی طرف اشارہ کرتی ہے۔

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Cisco کے ڈبے پر متبادل کردار پر منحصر ہے، اور درست نحو پلیٹ فارم اور ریلیز پر منحصر ہے: IPsec ساتھیوں کے لیے show crypto session، GRE یا سرنگ انٹرفیس کے لیے انٹرفیس کاؤنٹر، اور ڈائل اِن کردار کے لیے VPDN یا PPP تصدیق۔ وہ کمانڈ سیٹ جو PPP ختم کرتا ہے GRE معاونت کے بارے میں کچھ ثابت نہیں کرتا، اور چلتی GRE انٹرفیس PPP خدمت کے بارے میں کچھ ثابت نہیں کرتی، اس لیے خاکے والا نہیں، وہ کردار جانچیں جو آپ نے واقعی ترتیب دیا۔

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

توڑنے کی ترتیب بنائیں، پھر دوبارہ جانچیں

توڑنا اُلٹ ترتیب سے چلتا ہے، ایک وجہ سے: محفوظ ٹریفک کو IPsec پالیسی سے نکالیں، اُس لفافہ بندی کو ہٹانے سے پہلے جس کے لیے وہ لکھی گئی تھی، ورنہ پالیسی ایسی انٹرفیس کی طرف اشارہ کرتی رہتی ہے جو اب موجود نہیں اور اگلی ترتیب کی لوڈنگ کسی غیر متعلق جگہ پر ناکام ہوتی ہے۔ Linux پر اس کا مطلب سرنگ انٹرفیس سے پہلے حالت اور پالیسی اندراجات مٹانا ہے؛ راؤٹر پر، سرنگ سے پہلے کرپٹو نقشہ یا پروفائل اندراج ہٹانا۔

دوبارہ تعمیر کے بعد، قبولیت کے چار مشاہدے ایک ایک کر کے دہرائیں: بیرونی رسائی، قائم شدہ IPsec انجمن، جہاں ڈیزائن میں شامل ہو وہاں قائم شدہ PPP سیشن، اور حقیقی منزل پتے تک اندرونی ترسیل۔ ایک سبز بتی باقی تین کے لیے ثبوت نہیں، اور وہی خلا وہ ناکامی ہے جو پیداوار میں سب سے زیادہ دیر تک زندہ رہتی ہے — سرنگ چل رہی ہے، خفیہ ہے، اور کچھ آگے نہیں بھیج رہی کیونکہ اندرونی راستہ کبھی شامل نہیں کیا گیا۔

بھری ہوئی ورک شیٹ آلے کی ترتیب کے پاس رکھیں۔ آپ جو بھی ستون نہیں بھر سکتے وہ بے کام تہہ ہے، اور بے کام تہہ عموماً وہ تہہ ہے جو ڈھیر میں نہیں ہونی چاہیے۔