جہاں براؤزر کا HTTPS کامیاب ہوتا ہے وہاں SSTP ناکام ہوتا ہے: کیوں
SSTP پورٹ 443 پر TLS کے اندر چلتا ہے، لیکن یہ ویب درخواست نہیں ہے۔ TCP، TLS شناخت، SSTP تبادلہ اور PPP تصدیق کو الگ مراحل کے طور پر جانچیں۔
براؤزر VPN ہوسٹ نام کو HTTPS پر بغیر کسی شکایت کے کھولتا ہے، اور SSTP کلائنٹ پھر بھی جڑنے سے انکار کرتا ہے۔ اس جوڑی میں کوئی تضاد نہیں ہے۔ SSTP TLS کو بیرونی ترسیل کے طور پر استعمال کرتا ہے اور پھر اسی کنکشن کے اندر اپنی درخواست اور PPP پے لوڈ چلاتا ہے، اس لیے صفحے کا کامیاب لوڈ ہونا صرف ایک تنگ بات ثابت کرتا ہے: ہوسٹ پورٹ 443 پر GET کا جواب دیتا ہے۔ کلائنٹ کوئی اور سوال پوچھ رہا ہے، اور سرور اس کا جواب بری طرح دے سکتا ہے۔
صفحہ لوڈ ہوتا ہے اور ٹنل نہیں
لوگ براؤزر ٹیسٹ کی طرف اس لیے جاتے ہیں کہ یہ تیز ہے، پھر نتیجے کو اس بات کا ثبوت سمجھتے ہیں کہ سرور قابل رسائی اور کنفیگر ہے۔ یہ ایڈریس بار کے کھولے گئے راستے پر GET کا ثبوت ہے، اس سے زیادہ نہیں۔ VPN گفتگو اسی TLS ہینڈ شیک کے بعد شروع ہوتی ہے، لیکن بھیجتی ہے ایسا طریقہ اور راستہ جو ویب صفحہ کبھی استعمال نہیں کرتا۔ اس لیے براؤزر کے لیے 200 کا جواب اس بارے میں کچھ نہیں کہتا کہ SSTP اینڈ پوائنٹ موجود ہے یا نہیں۔
دونوں مشاہدوں کو الگ کریں اور تلاش مختصر ہو جاتی ہے۔ ترسیل اور سرٹیفکیٹ زنجیر کام کرتے ہیں، اور ان کے اوپر پروٹوکول تبادلے میں کچھ کام نہیں کرتا۔ یہ ٹوٹے پورٹ یا ختم شدہ سرٹیفکیٹ سے مختلف تفتیش ہے، اور اسے مختلف شواہد چاہیے۔
SSTP کلائنٹ اصل میں کیا بھیجتا ہے
کلائنٹ /sra_{GUID}/ راستے پر SSTP_DUPLEX_POST طریقے سے HTTP درخواست بھیجتا ہے، پھر کنکشن کے باڈی کو PPP فریم اٹھانے والی دو طرفہ ندی کے طور پر کھلا رکھتا ہے۔ موافق سرور HTTP/1.1 200 کا جواب دیتا ہے اور ویب سرور کی طرح برتاؤ کرنا چھوڑ دیتا ہے۔ باقی سب ایک دستخط ہے: 405 یا 404 کا مطلب اینڈ پوائنٹ نہیں ہے، 301 یا 302 کا مطلب کوئی چیز درخواست کو ری ڈائریکٹ کر رہی ہے، اور فوری FIN کا مطلب پراکسی یا سرور نے ندی بند کر دی۔
اسی لیے ہدف TLS سرٹیفکیٹ لگا ویب سرور نہیں، بلکہ SSTP سرور ہونا چاہیے۔ طریقہ، راستہ اور طویل باڈی پروٹوکول کی ضروریات ہیں، اس لیے ریورس پراکسی انہیں صرف کنفیگریشن سے نہیں جوڑ سکتی۔ عام HTTPS کو مکمل طور پر آگے بھیجنے والی پراکسی بھی ایسا طریقہ مسترد کر سکتی ہے جسے وہ نہیں پہچانتی۔
پراکسی یا ویب سرور ندی کہاں توڑتا ہے
ثالث کچھ بھی آگے بھیجنے سے پہلے HTTP درخواست لائن دیکھتا ہے، اور غیر معمولی راستے والا حسب ضرورت طریقہ اس کے قواعد میں ناکام ہو سکتا ہے۔ کچھ آلات عام صفحہ پیش کرتے ہیں جبکہ ٹنل مسترد یا منقطع کرتے ہیں، اس لیے کلائنٹ صاف انکار کے بجائے شروع ہو کر مرنے والے کنکشن کی اطلاع دیتا ہے۔ دیگر درخواست قبول کرتے ہیں، پھر باڈی یا بے کاری کی ایسی مدت لگاتے ہیں جو PPP کیپ الائیو برداشت نہیں کر سکتے۔ کلائنٹ کی طرف سے دونوں ایک جیسے لگتے ہیں، اس لیے کون سا مرحلہ ناکام ہوا یہ خرابی کے متن سے زیادہ اہم ہے۔
ویب سائٹ اور SSTP کے درمیان پورٹ 443 مشترک کرنا روٹنگ کا انتخاب ہے، ہر ہاپ دونوں گفتگوؤں کو ایک جیسا سنبھالے گا یہ وعدہ نہیں۔ اگر راستے میں لوڈ بیلنسر، فائر وال یا TLS ٹرمینیٹر ہو، تو VPN کنفیگریشن چھونے سے پہلے اسے مشتبہ فہرست میں شامل کریں۔
مراحل کو الگ الگ جانچیں
جانچیں ترتیب سے چلائیں اور پہلی ناکامی پر رکیں، کیونکہ ہر مرحلہ الگ تہہ خارج کرتا ہے۔ نیچے دیا TLS پروب سرٹیفکیٹ کی شناخت کو SSTP کے ہر عمل سے الگ کرتا ہے۔ ہوسٹ نام کو اپنے اینڈ پوائنٹ سے بدلیں اور جو subject اور زنجیر وہ چھاپتا ہے پڑھیں۔
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comپھر کلائنٹ خرابی سے اندازہ لگانے کے بجائے باقی شواہد کو مراحل سے ملائیں۔ نیچے دیا جدول ٹکٹ میں نقل کرنے کی فہرست ہے، اس دستخط کے ساتھ جو ایک ناکامی کو اگلی سے الگ کرتا ہے۔
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
ٹکٹ میں "جڑ نہیں سکتا" لکھنے کے بجائے آخری کامیاب مرحلہ درج کریں۔ MS-SSTP تفصیل TLS ہینڈ شیک کے بعد آنے والی درخواست اور PPP تبادلے کو دستاویز کرتا ہے، اور براؤزر ٹیسٹ دونوں میں سے کسی کا متبادل کیوں نہیں ہو سکتا اس کا حوالہ یہی ہے۔
پہلے شناخت، پھر PPP
TLS شناخت اور PPP تصدیق یکے بعد دیگرے ہیں، متبادل نہیں، اور انہیں ملانا لوگوں کو غلط سرور سیٹنگ کی طرف بھیجتا ہے۔ کلائنٹ پہلے سرور سرٹیفکیٹ اور اس کا مقصود مقصد جانچتا ہے، پھر PPP اپنی حالت پر بات چیت کرتا ہے اور صارف کی تصدیق چیلنج جواب طریقے یا EAP سے کرتا ہے۔ سرٹیفکیٹ کا مسئلہ مسترد شدہ پاس ورڈ سے مختلف خرابی دیتا ہے، اور کوئی خرابی دوسرے کے ڈھانپے مرحلے کی وضاحت نہیں کرتی۔
ہوسٹ نام کو پتے سے بدلنا، یا سرٹیفکیٹ انتباہ کو عبور کر کے کلک کرنا، ناکام ہونے والے مرحلے کی شناخت کرنے والی جانچ کو ٹھیک کرنے کے بجائے ہٹا دیتا ہے۔ انتباہ رکھیں اور اسے پڑھیں۔ جب HTTP تبادلہ کبھی SSTP برتاؤ تک نہ پہنچا تو PPP پاس ورڈ ری سیٹ نہ کریں، کیونکہ اسناد کبھی نہیں مانگی گئیں۔