SSTP ٹائم آؤٹ یا سرٹیفکیٹ کی غلطی: دونوں میں فرق کیسے کریں

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

دو ناکامیاں، دو مختلف تبادلے

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

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

لاگ کی سطر عام طور پر بتاتی ہے کہ آپ تینوں میں سے کس میں ہیں، اس لیے پہلی تبدیلی سے پہلے اسے محفوظ کرنا مناسب ہے۔

ٹائم آؤٹ کا مطلب ہے کہ کوئی مرحلہ کبھی مکمل نہیں ہوا

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

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

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

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

سرٹیفکیٹ کی غلطی کا مطلب ہے کہ شناخت مسترد ہوئی

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

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

کامیاب TLS مرحلہ گزرنے کے بعد اسے جوں کا توں رکھیں، کیونکہ بعد میں اسے واپس کرنا یہ چھپا دیتا ہے کہ کس تبدیلی نے سرنگ واقعی درست کی۔

دونوں کہاں الجھتے ہیں

دونوں ناکامیاں ایسے کنکشن کی صورت میں ظاہر ہوتی ہیں جو اٹھتا نہیں، اور دونوں اس وقت آتی ہیں جب صارف نے کوئی غیر متعلق چیز بدلی ہو۔ یہی اتفاق غلط مرمت کو کچھ دیر قابلِ فہم دکھاتا ہے۔

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

سرٹیفکیٹ کا سوال اور رسائی کا سوال کسی وجہ سے الگ درج کیے گئے ہیں۔

اصل کلائنٹ سے دوبارہ جانچیں، پھر اندر کی طرف بڑھیں

جب مخصوص اصلاح اپنی جگہ پر ہو، براؤزر ٹیب سے نہیں، اصل SSTP کلائنٹ اور حقیقی پروفائل سے دوبارہ کوشش کریں۔

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

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