L2TP/IPsec کو IPsec کے ساتھ UDP 1701 کی ضرورت کیوں ہے

وہ فائر والز جو IKE اور ESP کی اجازت دیتے ہیں مگر UDP 1701 کی نہیں، L2TP کنکشنز کو اس طرح توڑتے ہیں جو اسناد کے مسئلے جیسا لگتا ہے۔ وجہ یہ ہے کہ L2TP پہلے کے اندر سفر کرنے والا دوسرا پروٹوکول ہے۔ IPsec اس تبادلے کو لے کر جاتا اور تصدیق کرتا ہے، اور L2TP UDP 1701 پر اپنی سرنگ چلاتا ہے، جسے مقامی اسٹیک کو اب بھی پہنچانا ہوتا ہے۔ ہر ہیڈر کے ظاہر ہونے کی جگہ جاننا بتاتا ہے کہ کس ڈیوائس کو کون سا قاعدہ چاہیے۔

دو پروٹوکول، دو پورٹ سیٹ

L2TP/IPsec کنکشن UDP 500 پر IKE، جہاں ترجمہ ہو وہاں UDP 4500 پر NAT گزر، اور جہاں نہ ہو وہاں IP پروٹوکول 50 کے طور پر ESP استعمال کرتا ہے۔ L2TP خود UDP 1701 پر سرنگ پروٹوکول ہے، اور یہ IPsec کے ہم منصب کی تصدیق کے بعد چلتا ہے۔ دونوں نصف مختلف طریقے سے ناکام ہوتے ہیں، اور ان کی رپورٹ دینے والی لاگ سطریں مختلف اجزا سے آتی ہیں۔ صرف پہلے نصف کو ڈھانپنے والا قواعد کا مجموعہ ایسا کنکشن بناتا ہے جو بات چیت کر کے پھر سرنگ کے مرحلے پر مر جاتا ہے۔

پورٹ نمبر نقل و حمل کے آخری مقامات بیان کرتے ہیں، اور ESP بالکل پورٹ نہیں ہے۔ اسی لیے صرف TCP اور UDP قواعد پیش کرنے والا فائر وال انٹرفیس مکمل IPsec پالیسی بیان نہیں کر سکتا۔ پروٹوکول 50 کو بطور پروٹوکول اجازت دینی ہوگی، اور صرف UDP کا ذکر کرنے والا قاعدہ اس سے کبھی نہیں ملے گا۔

غلاف ہی پورٹ کی وضاحت کرتا ہے

تار پر، L2TP/IPsec کنکشن عام طور پر 500 پر IKE اور 4500 پر لپٹا ہوا ESP دکھاتا ہے۔ UDP 1701 ہیڈر محفوظ پے لوڈ کے اندر بیٹھتا ہے، اسی لیے بیرونی انٹرفیس پر کیپچر اسے نہیں دکھاتا۔ مقامی ہوسٹ کو وہ ڈیٹا گرام L2TP ڈیمون تک اب بھی پہنچانا ہوتا ہے، اور پہنچانا ڈی کپسولیشن کے بعد ہوتا ہے۔ اس لیے 1701 قاعدہ اینڈ پوائنٹ ہی کی فائر وال کا ہے، چاہے کوئی درمیانی ڈبہ وہ پورٹ کبھی نہ دیکھے۔

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

ترتیب سے راستہ جانچیں

پہلے بیرونی انٹرفیس پر کیپچر کریں اور تصدیق کریں کہ IKE اور لپٹا ہوا ESP دونوں سمتوں میں چل رہے ہیں۔ پھر ڈی کپسولیٹ شدہ ٹریفک کے لیے مقامی فائر وال کے کاؤنٹر دیکھیں۔ ترتیب اہم ہے، کیونکہ کچھ بھی نہ دکھانے والا کیپچر یعنی مسئلہ ہوسٹ سے اوپر ہے۔

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

کیپچر تبادلے کے پہلے نصف کی تصدیق کرتا ہے اور دکھاتا ہے کہ ہم منصب جواب دے رہا ہے یا نہیں۔ قواعد کی فہرست دکھاتی ہے کہ 1701 قاعدہ موجود ہے یا نہیں اور کسی بھی ڈراپ پالیسی کے مقابلے میں کہاں بیٹھتا ہے۔ ساکٹ کی فہرست تصدیق کرتی ہے کہ L2TP ڈیمون بندھا ہوا ہے اور سن رہا ہے، جو کبھی شروع نہ ہونے والی سروس کو خارج کرتا ہے۔ قاعدہ بدلنے سے پہلے تینوں پڑھیں، کیونکہ غیر موجود سامع اور فلٹر شدہ پورٹ صارف کی طرف سے ایک ہی شکایت پیدا کرتے ہیں۔

پورٹ اسکین کیا نہیں دکھا سکتا

درست طریقے سے ترتیب دیے گئے سرور کے خلاف UDP 1701 کا بیرونی اسکین عام طور پر کچھ نہیں بتاتا، اور یہی متوقع نتیجہ ہے۔ پورٹ انٹرنیٹ پر کھلا نہیں ہے؛ اس تک صرف اس وقت پہنچا جاتا ہے جب IPsec ہم منصب کی تصدیق کر چکا ہو۔ بند نتیجے کو خرابی سمجھنے سے ایسا پورٹ کھل جاتا ہے جو بند ہی رہنا چاہیے۔ اسکین سرنگ کے اندر اتنا ہی نہیں دیکھ سکتا جتنا یہ ایپلیکیشن کی ٹریفک نہیں دیکھ سکتا۔

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