SSTP مقابل OpenVPN: المنفذ 443 نفسه، لكن البروتوكول مختلف

يمكن أن يقف الخياران خلف TCP 443، فيفترض الناس أنهما نقطتا نهاية قابلتان للتبادل. الأمر ليس كذلك: SSTP يتحدث PPP داخل HTTPS، بينما يتحدث خادم OpenVPN بروتوكوله الخاص فوق TLS أو عبر تدفق UDP خام. وتوجيه عميل أحدهما إلى منفذ الآخر ينتج اتصالًا لا يصل أبدًا إلى شاشة تسجيل الدخول. والاختيار يتعلق بـ العميل والنقل اللذين يمكنك دعمهما، وليس بالرقم.

المنفذ المشترك لا يصنع بروتوكولًا مشتركًا

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

لا يحوّل أي ملف تعريف مُعاد تسميته ولا أي إدخال قائمة مختلف أحدهما إلى الآخر. يُنشأ اتصال SSTP من إعدادات VPN في Windows بعنوان خادم وتفاصيل مصادقة المشغّل، بينما يحتاج اتصال OpenVPN إلى العميل وملف التكوين المطابق. مواصفة SSTP من Microsoft تصف الحالة الأولى، ولا تصف مصافحة OpenVPN.

المنفذ 443 مسألة سياسة مريحة. فهو يمر عبر الشبكات التي لا تسمح بغير القليل، وهذه ميزة حقيقية، لكنه لا يخبرك بشيء عن البروتوكول الذي يعمل خلفه.

SSTP يغلّف PPP داخل HTTPS

الاسم يصف البناء: إطارات PPP محمولة داخل جلسة HTTPS، أي TLS في الأسفل وشهادة يمكن للعميل التحقق منها. ويضمّن Windows هذا كنوع VPN أصلي، لذا يمكن لجهاز كمبيوتر محمول مُدار أن يتصل غالبًا دون أي برنامج إضافي يتجاوز ملف التعريف الذي يوفره المشغّل.

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

SSTP عادةً TCP فقط. وهذا النقل الواحد يؤثر على سلوكه على وصلة يكثر فيها الفقدان، لأن إعادة الإرسال تحدث داخل النفق وأيضًا تحته.

OpenVPN يجلب عميله الخاص وخيارًا في النقل

يشحن OpenVPN عميله وملف تعريفه، ما يمنحك تشخيصًا لا يعرضه مربع حوار Windows الأصلي. ويمكن للخادم الاستماع على UDP أو TCP، وتكوين المشغّل يحدد أيّهما يجب أن يستخدمه عميلك. وملف التعريف الموجّه إلى النقل الخطأ يفشل قبل المصادقة.

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

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

اختر حسب العميل والنقل والدعم

ثلاثة أسئلة تحسم معظم هذه القرارات. هل يحتاج كل جهاز عميل إلى اتصال يعمل دون أي برنامج إضافي؟ وهل تسمح الشبكة التي تعتمد عليها بـ UDP، أم أن TCP 443 هو المخرج الوحيد؟ ومن يدعم العميل وتحديثاته وتعافيه عندما ينتهي ملف التعريف؟

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

ثم تأكّد من أيّهما أنشأت فعلًا قبل أن تنقّح أي شيء آخر:

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

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

في أسطول مُدار، يحدد توزيع ملفات التعريف ودعم التحديثات المسألة عادةً قبل أي قياس أداء للنقل بوقت طويل.