TLS کی جانچ کرنے والے پراکسی کے پیچھے SSTP: سیشن کہاں ٹوٹتا ہے

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

وہیں سے شروع کریں جہاں کلائنٹ رکتا ہے

کلائنٹ ایک مقررہ ترتیب سے گزرتا ہے: پورٹ 443 پر TCP کنکشن، TLS ہینڈ شیک، سرٹیفکیٹ کی توثیق، SSTP کا HTTP تبادلہ، PPP گفتگو اور توثیق، پھر IP ترتیب۔ ہر مرحلے کی ناکامی الگ نشان چھوڑتی ہے، اور انہیں ملانا آپ کو غلط ترتیب والے صفحے پر لے جاتا ہے۔

TCP ناکامی کسی بھی TLS بائٹ کے ظاہر ہونے سے پہلے ٹائم آؤٹ یا ری سیٹ ہے۔ TLS ناکامی انتباہ یا ہینڈ شیک ٹائم آؤٹ ہے۔ سرٹیفکیٹ ناکامی زنجیر یا نام کے بارے میں انتباہ دیتی ہے۔ HTTP ناکامی کامیاب ہینڈ شیک کے بعد آتی ہے، اکثر اسٹیٹس کوڈ یا فوری بندش کی صورت میں۔ PPP ناکامی ٹنل کے تکنیکی طور پر قائم ہونے کے بعد آتی ہے، اسی لیے وہ توثیق کے مسئلے جیسی لگتی ہے۔

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

SSTP نیٹ ورک سے کیا ڈھونے کو کہتا ہے

SSTP TCP 443 پر TLS کے اوپر چلتا ہے اور پھر SSTP تصریح میں بیان کردہ SSTP_DUPLEX_POST نامی HTTP درخواست /sra_{GUID}/ کی شکل والے راستے پر بھیجتا ہے۔ درخواست عملاً لامحدود مواد کی لمبائی کا اعلان کرتی ہے اور سیشن کی پوری زندگی میں سٹریم کو دونوں سمتوں میں کھلا رکھتی ہے۔ PPP فریم اسی سٹریم کے اندر سفر کرتے ہیں۔

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

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

جانچ شناخت کیوں بدلتی ہے

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

کامیاب توثیق کا مطلب یہ نہیں کہ پراکسی سیشن ڈھو سکتا ہے۔ اسے ابھی بھی بفرنگ کے بغیر لامحدود دو طرفہ POST ریلے کرنا ہے اور دونوں کنکشن گھنٹوں زندہ رکھنے ہیں۔ بہت سی جانچ مصنوعات درخواست-جواب ٹریفک کے لیے بنی ہیں اور یہ معاملہ بری طرح یا بالکل نہیں سنبھالتیں۔

اسی لیے نامعلوم جڑ شامل کرنا یا توثیق بند کرنا غلط مرمت ہے۔ یہ بدلتا ہے کہ کلائنٹ کون سا سرٹیفکیٹ قبول کرتا ہے؛ سیشن کو حقیقتاً توڑنے والی سٹریم ہینڈلنگ کے بارے میں یہ کچھ نہیں کرتا۔

ترتیبات بدلنے سے پہلے جاری کنندہ کی شناخت کریں

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

اگر جاری کنندہ عوامی CA ہے، تو اس ہوسٹ کے لیے کنکشن روکا نہیں جا رہا اور ناکامی کہیں اور ہے۔ اگر جاری کنندہ ادارے کا اپنا CA ہے، تو جانچ فعال ہے اور گیٹ وے تک پراکسی کے ذریعے پہنچا جاتا ہے۔ صرف نام سے نتیجہ نکالنے سے پہلے فنگر پرنٹ کا موازنہ نیٹ ورک ٹیم کی توقع سے کریں۔

اسی ہوسٹ پر براؤزر ٹیسٹ صرف یہ ثابت کرتا ہے کہ پراکسی GET قبول کرتا ہے۔ یہ SSTP طریقہ، درخواست کا URI یا باڈی کی عمر کے بارے میں کچھ نہیں کہتا، اس لیے چلتی انٹرانیٹ صفحے کو ٹنل راستے کی حمایت کا ثبوت نہ سمجھیں۔

معاون راستہ منتخب کریں

نیٹ ورک مالک سے ایک واضح سوال پوچھیں: کیا پراکسی اس گیٹ وے کی طرف پورٹ 443 پر بغیر بفر دو طرفہ POST کی اجازت دیتا ہے؟ ہاں کا مطلب پراکسی میں استثنا یا VPN ہوسٹ کے لیے دستاویزی راستہ ہے۔ نہیں کا مطلب ہے کہ جانچا گیا راستہ SSTP نہیں ڈھو سکتا، اور معاون حل کلائنٹ کی اصلاح نہیں، بلکہ دوسرا راستہ یا پروٹوکول ہے۔

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

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