SSTP پہلے سرور کی اور بعد میں صارف کی توثیق کرتا ہے

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

قابلِ بھروسہ سرٹیفکیٹ اختتامی نقطے کو ثابت کرتا ہے؛ اکاؤنٹ کے بارے میں یہ کچھ نہیں بتاتا۔

TLS ہینڈ شیک کیا قائم کرتا ہے

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

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

SSTP اور PPP اوپر کیا اضافہ کرتے ہیں

SSTP HTTPS پر چلتا ہے اور اندر PPP اٹھائے چلتا ہے، رابطے کے گرد اپنی کنٹرول تبادلے کے ساتھ۔ پھر PPP اپنے لنک اور توثیق کے مراحل چلاتا ہے، اور توثیق کا طریقہ سرور کی پالیسی اور کلائنٹ کی صلاحیت پر منحصر ہے۔ PAP، CHAP، MS-CHAPv2 اور EAP سب بہت مختلف خصوصیات والے PPP توثیق کے اختیارات ہیں۔ VPN کی صارف جانچ وہی PPP مرحلہ ہے، اس کے نیچے کی TLS تہہ نہیں۔

اس لیے صارف کا مسترد ہونا اسناد، اکاؤنٹ پر پابندی یا طریقے کی عدم مطابقت کا مطلب ہو سکتا ہے۔

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

غلطی کو مرحلے سے جوڑیں

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

یہی ہم آہنگی سرور کی طرف بھی اہم ہے، جہاں توثیق کا ریکارڈ اور نقل و حمل کا لاگ اکثر الگ گھڑیوں والی الگ فائلیں ہوتے ہیں۔ دو منٹ کا فرق کسی واضح وجہ کو ناممکن دکھانے کے لیے کافی ہے۔

لاگ ان کے بعد بھی اجازت الگ ہے

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

یہ وہی تہہ بندی ہے جو ہینڈ شیک نے دکھائی، ایک درجہ اوپر۔

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