مهلة 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

المهلة قبل أي رد من النظير لا تقول شيئاً عن الحساب، وتغيير كلمة المرور عند تلك النقطة لا يضيف إلا متغيراً.

خطأ الشهادة يعني أن الهوية رُفضت

هنا أجاب الخادم فعلاً، فالشبكة تعمل وينتقل السؤال إلى الهوية. قارن الاسم الذي يطلبه العميل بالأسماء التي تؤكدها الشهادة فعلاً، ثم افحص تواريخ الصلاحية وسلسلة الإصدار.

سلطة شهادات خاصة لا يثق بها العميل تُنتج الصنف نفسه من الخطأ الذي تنتجه شهادة منتهية، وكذلك ساعة متأخرة بساعات. طلب العنوان الخام يُنشئ عدم تطابق جديداً، لأن الشهادة تؤكد أسماء لا عناوين. في نشر مُدار، احصل على إعداد الثقة المقصود من مسؤوله بدلاً من قبول جذر بديل تعرضه صفحة خطأ. يبقى التحقق مفعلاً بينما تصلح السبب.

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 والمصادقة العاملتين يمنع أن يصبح تكراراً للأولى. اكتب المرحلة التي فشلت في التذكرة، وإلا سيبدأ الشخص التالي من القمة مرة أخرى.