MSCHAPv2 کوئی VPN پروٹوکول نہیں: پہلے سرنگ کے بارے میں پوچھیں

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

تصدیق سرنگ کے اندر سفر کرتی ہے

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

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

وہی طریقہ نظر آنے کی تین جگہیں

PPP میں تصدیق کا مرحلہ لنک موجود ہونے تک انتظار کرتا ہے، اور RFC 2759 MS-CHAPv2 کو وہی مرحلہ قرار دیتا ہے، اسی لیے یہ طریقہ L2TP اور پرانی PPTP تعیناتیوں میں نظر آتا ہے۔ سرنگ پہلے ختم ہوتی ہے اور PPP گفتگو اس کے اندر ہوتی ہے، اس لیے ناکام PPP مرحلہ سرور لاگ میں سرنگ کو قائم شدہ جیسا چھوڑ سکتا ہے۔ اس نتیجے پر پہنچنے سے پہلے کہ اسناد مسترد ہوئیں، ان دو مرحلوں کو الگ الگ پڑھیں۔ چنانچہ L2TP کے لیے ترتیب دیا گیا کلائنٹ مکمل درست ہو سکتا ہے اور پھر بھی اس گیٹ وے کے لیے غلط کلائنٹ ہو سکتا ہے جو صرف IKEv2 بولتا ہے۔

IKEv2 اس کے بجائے EAP-MSCHAPv2 کو کلیدی تبادلے کے اندر رکھتا ہے، اس لیے وہی سند کسی اور لمحے ناکام ہوتی ہے اور سیشن کی خرابی کے بجائے تصدیق کی خرابی کے طور پر سامنے آتی ہے۔ Android پلیٹ فارم کا IKEv2 پروفائل روزمرہ مثال ہے، اور یہ PPP اختیارات کے بجائے سرور سرٹیفکیٹ یا شناخت کنندہ مانگتا ہے۔ اکاؤنٹ نام دونوں ترتیبوں میں یکساں ہے، اس لیے یہ نہیں بتا سکتا کہ آپ کے پاس کون سا ہے۔ یہ صرف عامل کی معاون پروٹوکول فہرست طے کرتی ہے۔

TLS پر مبنی VPN تیسری ترتیب جوڑتا ہے، اپنے صارف نام اور پاس ورڈ خانوں کے ساتھ اور تبادلے میں کہیں بھی MS-CHAPv2 کے بغیر۔ اس لیے پاس ورڈ خانہ دیکھنا اس کے پیچھے کے پروٹوکول کا ثبوت نہیں، کیونکہ فارم کو جانا پہچانا لگنے کے لیے بنایا گیا ہے۔ پروٹوکول کی تصدیق کلائنٹ ونڈو کی شکل سے نہیں، سرور کی دستاویزات سے کریں۔

وہ جوابات جن کی آپ کو واقعی ضرورت ہے

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

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

گیٹ وے کی جانچ ڈھیلی نہ کریں

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

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

پروفائل ملائیں، پھر ہر مرحلہ ثابت کریں

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

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