کیوں صرف PPP CHAP MPPE کی ضرورت پوری نہیں کر سکتا

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

ایک ہی PPTP کنکشن کے اندر دو گفت و شنید چلتی ہیں

PPTP GRE ٹنل کے اندر عام PPP سیشن لے کر چلتا ہے، اور دونوں الگ الگ گفت و شنید کرتے ہیں۔ بیرونی پرت طے کرتی ہے کہ پیکٹ کیسے انکیپسولیٹ ہوں گے اور کون سا کنٹرول چینل موجود ہے؛ اندرونی PPP سیشن طے کرتا ہے کہ ساتھی کون ہے اور اوپر کون سا تحفظ چل رہا ہے۔ اس لیے پاس ورڈ کی درخواست صرف اندرونی پرت کے بارے میں کچھ ثابت کرتی ہے، اور مکمل شدہ بیرونی ہینڈ شیک دونوں میں سے کسی کے بارے میں کچھ ثابت نہیں کرتا۔ پروفائل یہاں ناکام ہوتے ہیں کیونکہ لوگ ٹنل ڈی بگ کرتے ہیں جبکہ اختلاف PPP کے اندر بیٹھا ہوتا ہے۔

سادہ CHAP RFC 1994 کی چیلنج جواب منتقلی ہے، جو مشترکہ راز اور کچھ نہیں پر بنی ہے۔ MS-CHAPv2 مختلف پیغامات اور مختلف آؤٹ پٹ کے ساتھ دوسری منتقلی ہے، RFC 2759 میں معیاری بنائی گئی۔ دونوں ناموں کا مشترک لفظ ہی وہ واحد چیز ہے جو تار پر ان میں مشترک ہے۔ کوئی نام یہ نہیں بتاتا کہ منتقلی کیا پیدا کرتی ہے، اور یہی واحد اہم حصہ ہے۔

اسی لیے صرف CHAP کا لیبل لگا آپشن پرانے پروفائل میں مبہم ہے۔ جب سرور MS-CHAPv2 چاہتا ہے اور کلائنٹ سادہ CHAP پیش کرتا ہے، لنک کنٹرول پھر بھی مکمل ہو سکتا ہے اور پاس ورڈ پھر بھی قبول ہو سکتا ہے۔ ناکامی بعد میں آتی ہے، جب سرور ایسی منتقلی سے تحفظ کی کلیدیں نکالنے کی کوشش کرتا ہے جس نے کچھ پیدا نہیں کیا۔

مطلوبہ طریقے کو ان کلیدوں سے ملائیں جو وہ پیدا کر سکتا ہے

MPPE کی کلیدیں عام طور پر PPP کی خصوصیت نہیں ہیں۔ Microsoft CHAP خاندان کے لیے اخذ RFC 3079 میں بیان کیا گیا ہے، اور یہ ان پٹ کے طور پر مشترکہ راز کی بجائے MS-CHAP منتقلی کا آؤٹ پٹ لیتا ہے۔ EAP طریقے کسی اور راستے سے اسی جگہ پہنچتے ہیں، جہاں تصدیق کا سرور کلیدیں MS-MPPE-Recv-Key اور MS-MPPE-Send-Key خصوصیات کے طور پر واپس کرتا ہے۔ سادہ CHAP دونوں راستوں میں کہیں نہیں آتا، اور یہی اس عدم مطابقت کے موجود ہونے کی پوری وجہ ہے۔

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

اس سے نکلنے والا اصول مختصر ہے: اگر پروفائل MPPE مانگتا ہے، تو طریقہ MS-CHAP کی قسم یا ایسا EAP طریقہ ہونا چاہیے جس کی کلیدیں سرور واپس کرتا ہے۔ صرف MS-CHAPv2 مسترد کرنا اسے لازم نہیں کرتا، کیونکہ MS-CHAPv1 بھی کلیدیں اخذ کرتا ہے اور الگ سے مسترد نہ کیے جانے تک دستیاب رہتا ہے؛ دونوں کو مسترد کرنے سے سادہ CHAP اور PAP بچتے ہیں، جو کچھ اخذ نہیں کرتے اور ضرورت کو ناقابلِ تکمیل بنا دیتے ہیں۔ جو آپ کو پسند نہیں ان کی فہرست بنانے کی بجائے منظور شدہ طریقے کا واضح نام دیں۔ کلائنٹ کے جڑنے کے لیے انکرپشن کی ضرورت چھوڑ دینا مرمت نہیں، تنزلی ہے۔

کلائنٹ میں ترمیم سے پہلے سرور کے اختیارات پڑھیں

ان میں سے بیشتر عدم مطابقتیں سرور پر دو فائلوں میں نظر آتی ہیں، اور انہیں پڑھنا کلائنٹ کو دوبارہ بنانے سے سستا ہے۔ Linux PPTP اینڈ پوائنٹ پر متعلقہ ترتیبات pppd کے اختیارات کی فائل میں رہتی ہیں جو pptpd آگے بھیجتا ہے۔ اسے سرور پر چلائیں، کلائنٹ کی حالت کی اسکرین سے نہیں۔ ان سطروں سے شروع کریں جو تحفظ کا موڈ مانگتی، مسترد کرتی یا نام دیتی ہیں:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

آؤٹ پٹ کو جھنڈوں کی فہرست نہیں، معاہدہ سمجھ کر پڑھیں۔ جو سطر MPPE مانگتی ہے مگر MS-CHAP کی دونوں اقسام مسترد کرتی ہے، اسے کوئی کلائنٹ پورا نہیں کر سکتا، اور MS-CHAP طریقے کے لیے ضرورت کا نہ ہونا کلید نہ دینے والی منتقلیوں کے لیے دروازہ کھلا چھوڑ دیتا ہے۔ پھر جانچیں کہ کسے تصدیق کی اجازت ہے، یہ راز کی فائل طے کرتی ہے:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

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

PPP مرحلے کے مطابق ناکامی تلاش کریں

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

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

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

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

پرانے اینڈ پوائنٹ کے بند ہونے سے پہلے نکلنے کا منصوبہ بنائیں

MPPE لنک تحفظ کا ایک تاریخی طریقہ کار ہے، اور اس کی موجودگی PPTP کو نئی تعیناتی کے لیے معقول انتخاب نہیں بناتی۔ Microsoft کی موجودہ رہنمائی پہلے ہی نئی ریموٹ ایکسیس تعیناتیوں کے لیے PPTP اور پیشگی مشترکہ کلید والے L2TP/IPsec کے خلاف مشورہ دیتی ہے۔ پرانے اینڈ پوائنٹ کو زندہ رکھنا موجودہ سروس کے بارے میں فیصلہ ہے، اگلی کے لیے نمونہ نہیں۔

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

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