فشل SSTP حيث ينجح HTTPS في المتصفح: السبب
يعمل SSTP داخل TLS على المنفذ 443، لكنه ليس طلب ويب. اختبر TCP وهوية TLS وتبادل SSTP ومصادقة PPP كمراحل منفصلة.
يفتح المتصفح اسم مضيف VPN عبر HTTPS دون أي شكوى، ومع ذلك يرفض عميل SSTP الاتصال. لا شيء في هذا الاقتران متناقض. يستخدم SSTP بروتوكول TLS كناقل خارجي ثم يشغّل طلبه الخاص وحمولة PPP داخل ذلك الاتصال، لذا فإن تحميل صفحة بنجاح يثبت أمرًا واحدًا ضيقًا: أن المضيف يجيب على طلب GET على المنفذ 443. العميل يطرح سؤالًا مختلفًا، وقد يجيبه الخادم بشكل سيئ.
الصفحة تُحمَّل والنفق لا
يلجأ الناس إلى اختبار المتصفح لأنه سريع، ثم يعاملون النتيجة كدليل على أن الخادم قابل للوصول ومهيأ. لكنه دليل على طلب GET إلى المسار الذي فتحه شريط العنوان، لا أكثر. تبدأ محادثة VPN بعد المصافحة نفسها لـ TLS، لكنها ترسل طريقة ومسارًا لا تستخدمهما صفحة ويب أبدًا. لذلك لا تقول استجابة 200 للمتصفح شيئًا عما إذا كانت نقطة نهاية SSTP موجودة.
افصل الملاحظتين وستقصر عملية البحث. النقل وسلسلة الشهادات يعملان، وشيء في تبادل البروتوكول فوقهما لا يعمل. هذا تحقيق مختلف عن منفذ معطل أو شهادة منتهية، ويحتاج أدلة مختلفة.
ما يرسله عميل SSTP فعليًا
يرسل العميل طلب HTTP بالطريقة SSTP_DUPLEX_POST إلى المسار /sra_{GUID}/، ثم يبقي جسم الاتصال مفتوحًا كتيار ثنائي الاتجاه يحمل إطارات PPP. يجيب الخادم الممتثل بـ HTTP/1.1 200 ويتوقف عن التصرف كخادم ويب. أي شيء آخر هو بصمة: 405 أو 404 يعني أن نقطة النهاية غير موجودة، و301 أو 302 يعني أن شيئًا يعيد توجيه الطلب، وFIN فوري يعني أن وكيلًا أو خادمًا أغلق التيار.
لهذا يجب أن يكون الهدف خادم SSTP وليس خادم ويب أُضيفت إليه شهادة TLS. الطريقة والمسار والجسم الطويل الأمد متطلبات بروتوكول، لذا لا يمكن لوكيل عكسي إضافتها من الإعداد وحده. الوكيل الذي يمرر HTTPS العادي بشكل مثالي قد يرفض مع ذلك طريقة لا يتعرف عليها.
أين يكسر الوكيل أو خادم الويب التيار
يفحص الوسيط سطر طلب HTTP قبل أن يمرر أي شيء، وقد تفشل طريقة مخصصة بمسار غير معتاد في قواعده. بعض الأجهزة تقدّم صفحة عادية بينما ترفض النفق أو تقاطعه، فيبلغ العميل عن اتصال يبدأ ثم يموت بدلًا من رفض نظيف. وأخرى تقبل الطلب ثم تطبق مهلة للجسم أو للخمول لا تستطيع رسائل إبقاء PPP البقاء معها. يبدو الاثنان متطابقين من جهة العميل، ولهذا فإن المرحلة التي فشلت أهم من نص الخطأ.
مشاركة المنفذ 443 بين موقع ويب وSSTP قرار توجيه، وليس وعدًا بأن كل قفزة تتعامل مع المحادثتين بالطريقة نفسها. إذا كان موازن حمل أو جدار ناري أو مُنهٍ لـ TLS في المسار، فأضفه إلى قائمة المشتبه بهم قبل أن تلمس إعداد VPN.
اختبر المراحل بشكل منفصل
نفّذ الفحوص بالترتيب وتوقف عند أول فشل، لأن كل مرحلة تستبعد طبقة مختلفة. مسبار TLS أدناه يفصل هوية الشهادة عن أي شيء يفعله SSTP. استبدل اسم المضيف بنقطة النهاية الخاصة بك واقرأ الموضوع والسلسلة التي يطبعها.
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 توضح الطلب وتبادل PPP الذي يلي مصافحة TLS، وهي المرجع لسبب عدم قدرة اختبار المتصفح على النيابة عن أي منهما.
الهوية أولًا، ثم PPP
هوية TLS ومصادقة PPP متتاليتان وليستا بديلين، والخلط بينهما يوجّه الناس إلى إعداد الخادم الخطأ. يتحقق العميل أولًا من شهادة الخادم ومن غرضها المقصود، ثم يتفاوض PPP على حالته الخاصة ويصادق على المستخدم بطريقة تحدٍّ واستجابة أو EAP. مشكلة الشهادة تنتج خطأً مختلفًا عن كلمة مرور مرفوضة، ولا يصف أي من الخطأين المرحلة التي يغطيها الآخر.
استبدال اسم المضيف بعنوان، أو النقر لتجاوز تحذير الشهادة، يزيل الفحص الذي كان سيحدد المرحلة الفاشلة بدلًا من إصلاحها. أبقِ التحذير واقرأه. ولا تعِد ضبط كلمة مرور PPP عندما لم يصل تبادل HTTP إلى سلوك SSTP أصلًا، لأن بيانات الاعتماد لم تُطلب قط.