SSTP خلف وكيل يفحص TLS: أين تنقطع الجلسة

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

ابدأ من حيث يتوقف العميل

يمر العميل بتسلسل ثابت: اتصال TCP بالمنفذ 443، ومصافحة TLS، والتحقق من الشهادة، وتبادل SSTP عبر HTTP، وتفاوض PPP والمصادقة، ثم إعداد IP. يترك كل فشل في مرحلة بصمة مختلفة، وخلطها يوجّهك إلى صفحة إعداد خاطئة.

فشل TCP هو مهلة أو إعادة تعيين قبل ظهور أي بايت من TLS. وفشل TLS هو تنبيه أو مهلة مصافحة. وفشل الشهادة ينتج تحذيرًا عن السلسلة أو الاسم. وفشل HTTP يأتي بعد مصافحة ناجحة، غالبًا كرمز حالة أو إغلاق فوري. وفشل PPP يأتي بعد إنشاء النفق تقنيًا، ولهذا يبدو كمشكلة مصادقة.

اقرأ سجل العميل بحثًا عن آخر مرحلة ناجحة بدلًا من أول سطر خطأ. سطر الخطأ عادةً ما يسجّل العميل فيه النتيجة، بينما يسمّي حدّ المرحلة المكوّن الذي رفض.

ما يطلبه SSTP من الشبكة أن تحمله

يعمل SSTP عبر TLS على TCP 443 ثم يرسل طلب HTTP اسمه SSTP_DUPLEX_POST، المعرّف في مواصفة SSTP، إلى مسار بالشكل /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/

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

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

اختر المسار المدعوم

اسأل مالك الشبكة سؤالًا واحدًا محددًا: هل يسمح الوكيل بطلب POST مزدوج غير مخزّن إلى هذه البوابة على المنفذ 443؟ الجواب بنعم يؤدي إلى استثناء في الوكيل أو تجاوز موثّق لمضيف VPN. والجواب بلا يعني أن المسار المفحوص لا يستطيع حمل SSTP، وأن الإصلاح المدعوم هو مسار أو بروتوكول آخر لا تعديل في العميل.

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

سجّل النتيجة: المُصدر، والمرحلة الفاشلة، وقاعدة الوكيل، والمسار المختار. حين يرى الشخص التالي نفس التوقف عند 98 بالمئة، يمكنه التحقق من حقيقة واحدة بدل تكرار الممر كله.