L2TP جڑتا ہے مگر PPP گفت و شنید ناکام ہوتی ہے: کون سا مرحلہ؟

IPsec سرنگ قائم ہوتی ہے، کلائنٹ محفوظ ساتھی دکھاتا ہے، اور پھر رابطہ نجی ذیلی نیٹ تک کچھ پہنچنے سے پہلے مر جاتا ہے۔ یہ خلا PPP کا اپنا کام ہے: لنک کے اختیارات، صارف کی تصدیق اور پتہ تفویض سب خفیہ کردہ سرنگ موجود ہونے کے بعد ہوتے ہیں۔ پہلے مرحلے کے کامیاب تبادلے سے کوئی پاس ورڈ یا اندرونی پتہ نہیں ملتا۔ مراحل ترتیب سے پڑھیں اور ناکامی عموماً خود اپنا نام بتا دیتی ہے۔

سرنگ صرف پہلی تہہ ہے

L2TP IPsec سے محفوظ سرنگ کے اندر PPP فریم لے کر جاتا ہے، یعنی پیکٹ کی راہ کاری سے پہلے دو آزاد گفت و شنید کامیاب ہونی چاہئیں۔ بیرونی ثابت کرتی ہے کہ دونوں سرے چابیوں اور شناختوں پر متفق ہیں۔ اندرونی لنک کے پیرامیٹر، صارف کی تصدیق اور کلائنٹ کو ملنے والا پتہ طے کرتی ہے۔

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

وہ آخری مرحلہ پڑھیں جو کامیاب ہوا

لاگ میں آگے بڑھیں اور پہلے اس مرحلے پر رکیں جو مکمل نہیں ہوا۔ پہلے LCP آتا ہے، پھر تصدیق، پھر IPv4 پیرامیٹرز کے لیے IPCP۔

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

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

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

کلائنٹ اور سرور کے درمیان اتفاق

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

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

پتہ جانچیں، لاگ ان نہیں

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

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

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

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