أي البروتوكولات يوفّرها حقًا عقد VPN العام هذا؟

البرمجية تدعمه، إذن العقد يوفّره. هذا الاستنتاج خاطئ بما يكفي ليصبح قاعدة: يمكن لنشر SoftEther أن يفعّل أي مجموعة فرعية من أساليب الاتصال المتوافقة، والعقد العام هو نشر له مالك وإعدادات. ما يمكنك الاتصال به يعتمد على ذلك العقد، لا على قائمة ميزات المشروع الذي يشغّله. والفجوة بين الاثنين هي حيث تعيش معظم تذاكر «البروتوكول معطّل».

ما الذي تعد به قائمة المشروع فعلًا

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

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

طابِق الملف الشخصي مع نقطة النهاية التي يسمّيها

مدخل SoftEther الأصلي ليس تلقائيًا إعدادًا لـ OpenVPN، حتى عندما يظهر الاثنان في صفحة مزوّد واحدة تحت عنوان واحد. وعندما ينشر عقد مستمعَي TCP وUDP لـ OpenVPN، تعامل معهما كنقطتَي نهاية: فالملف الشخصي المعدّل من أحدهما إلى الآخر يشير إلى مستمع لم يفعّله أحد. ووسم النقل في الملف جزء من العنوان، وليس إعدادًا شكليًا.

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

افحص المرحلة التي تفشل

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

هذه الفحوص الخمسة تغطي أساليب العقد العام الشائعة. نفّذها من الشبكة نفسها التي يستخدمها العميل، لأن المنفذ المفلتر يبدو مطابقًا لمستمع غائب من بعيد.

nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example

أسنِد كل خطأ مُلاحَظ إلى صفّه قبل تغيير أي شيء. فشل هوية TLS يثبت وجود المستمع، لذا فإن إعادة كتابة الملف الشخصي إلى بروتوكول آخر ستُهدر دليلًا عاملًا. والاتصال المرفوض يثبت فقط أن هذا المنفذ لم يجب، وهو بيان أضيق بكثير من «العقد لا يدعم OpenVPN».

احفظ الخطأ قبل تغيير أي شيء

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

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

أعِد الفحص لكل عقد، في كل مرة

خيارات SSL وOpenVPN وL2TP/IPsec وSSTP الأصلية في قائمة عقد عام تصف إعدادات ذلك العقد في تلك اللحظة. والبرمجية نفسها في مكان آخر قد تعرض مجموعة مختلفة، ويمكن للمزوّد أن يسحب مستمعًا بين إشارتك المرجعية ومحاولتك التالية. والملاحظات القديمة تصف عمليات نشر قديمة.

سجّل الملف الشخصي المتحقَّق منه مع نقطة نهايته وطريقته، ثم أعِد الفحص عندما يتغير العقد أو يبدأ الاتصال بالفشل. مواصفة بروتوكول SoftEther هي المرجع لما تستطيعه البرمجية؛ وقائمة العقد نفسه هي المرجع لما تفعله. أبقِ الوثيقتين منفصلتين يصبح التشخيص أقصر.