ملف تعريف مقفل بالخادم يفشل خلف وكيل TLS: أي جيل؟
يبني Access Server 2.8 و2.9 ملفات التعريف المقفلة بالخادم بطريقتين مختلفتين. قرر أي مسار يكسره الوكيل قبل تغيير الواجهة الأمامية.
يمكن لمستخدم واحد أن يتصل بينما لا يستطيع آخر، عبر البوابة نفسها، في اليوم نفسه. كلاهما يملك ملف تعريف مقفلًا بالخادم، وكلاهما على إصدار Access Server نفسه، والفرق الوحيد هو وقت إنشاء ملف التعريف. هذا هو النمط الجدير بالملاحظة، لأن عبارة "مقفل بالخادم" تصف سياسة لا تسلسل اتصال. أصدر Access Server جيلين من ذلك الملف، والوكيل العكسي TLS يقف أمام أحد مساريهما فقط. ثلاثة شروط تحدد الفرع الذي أنت فيه.
جيلان، وتسلسلا اتصال
في التصميم الأقدم، الساري حتى 2.8، الملف المستورد هو ملف تعريف شبه حقيقي. يستخدمه OpenVPN Connect للمصادقة على واجهة الويب البرمجية لـ Access Server عبر HTTPS، ثم يستلم ملف تعريف مقفلًا بالمستخدم مؤقتًا ورمز جلسة، وبعد ذلك فقط ينشئ الـ VPN. يعمل ناقلان بالتتابع، وأولهما طلب ويب عادي.
الصيغة التي أُدخلت مع 2.9 لا تنفذ ذلك الإقلاع لكل اتصال. إنه ملف تعريف أصلي يمكن استخدامه بواسطة عملاء OpenVPN متوافقين، وليس فقط بواسطة OpenVPN Connect. لا يزال تنزيله أو استيراده عبر عنوان URL قد يتضمن HTTPS — وهذه خطوة نشر، لا جلبًا لملف تعريف مؤقت لكل اتصال.
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
لا يعيد التحديث بالضرورة كتابة ملفات التعريف التي صدرت بالفعل، لذا قد يظل خادم حالي يوزع الملف القديم. يخبرك إصدار الخادم بما هو ممكن، لا بما استورده هذا المستخدم.
ثلاثة شروط تحدد فرعك
الشرط الأول هو جيل الملف. اطلب الملف، وانظر كيف أُنتج، وسجل إصدار العميل الذي استورده. إذا لم تستطع تحديد الجيل من الملف، فسيخبرك ملف تعريف جديد صادر لحساب اختبار بما ينتجه الخادم اليوم، وهذه معلومة مختلفة عما يملكه المستخدم المتعثر.
الثاني هو ما تنهيه الواجهة الأمامية فعليًا. الوكيل العكسي HTTP من الطبقة السابعة الذي يخفف TLS ليس الكائن نفسه الذي يمثله مُمرّر TCP من الطبقة الرابعة، ولا مُمرّر UDP كذلك. الترتيب المعتاد لـ Access Server على المنفذ 443 يجعل خدمة OpenVPN TCP تتعرف على حركة المتصفح وتسلمها إلى خدمات الويب، لذا فإن إدخال مُنهٍ HTTPS غير ذي صلة في المقدمة لا يحافظ على معالجة البروتوكول لدى تلك الخدمة. مشاركة الرقم 443 لا تجعل تصميمين متكافئين.
الثالث هو أين تقع المشكلة. فشل ما قبل الـ VPN وفشل قناة التحكم يبدوان متشابهين في عميل لا يقول سوى "يتصل"، لكنهما يتركان أدلة في مواضع مختلفة. إذا كانت الصيغة القديمة قيد الاستخدام فالإقلاع مرشح. وإذا كانت الصيغة الجديدة قيد الاستخدام فسجل وصول ويب فارغ أمر متوقع ولا يثبت شيئًا في أي اتجاه.
عندما يكون الملف قديمًا: يفشل الإقلاع أولًا
اقرأ خطأ العميل الفعلي بدلًا من حالته النهائية. الحقول المهمة هي خطأ HTTPS، وهوية الخادم التي توقعها العميل، والوجهة التي ذهب إليها الطلب، وما إذا اكتمل التحقق من الشهادة. ثم طابق ذلك مع سجلات خدمة الويب والوكيل على جانب الخادم.
وصول متصفح إلى صفحة تسجيل الدخول ليس دليلًا على نجاح مصادقة هذا العميل على الواجهة البرمجية. فهي طلبات مختلفة، بتوقعات شهادات مختلفة وأسماء مضيفين مختلفة غالبًا. إذا كانت البوابة تُخدم بشكل صحيح ولا يزال العميل يفشل، فالخلاف في مسار الإقلاع لا في كلمة مرور المستخدم.
لا تجعل المقارنة تنجح بتعطيل التحقق من TLS أو تخفيف سياسة المصادقة. فذلك يحول عدم تطابق إعدادات قابلًا للتشخيص إلى مسار يعمل دون تحقق، وهو بالضبط التغيير الذي يحول اختبارًا مؤقتًا إلى ثغرة دائمة. إن وثائق ملفات تعريف الاتصال في Access Server تصف الجيلين وتدفق ملف التعريف المؤقت، وهي المرجع الذي يجب فحصه قبل افتراض أن الوكيل هو السبب.
عندما يكون الملف جديدًا: اقرأ قناة التحكم بدلًا من ذلك
مع ملف تعريف بنمط 2.9، يذهب العميل مباشرة إلى نقطة نهاية الـ VPN الأصلية. افحص نقاط النهاية في ملف التعريف، والناقل المستخدم، وخطأ قناة التحكم. إذا لم يصدر العميل أي طلب HTTP، فهذا متوافق مع التصميم وليس عرضًا مرضيًا.
هنا أيضًا يتغير شكل سؤال الوكيل. لا يمكن لتفريغ HTTPS أن يكسر تدفق TCP فقط لا يراه أبدًا، لكنه قد يكسر التنزيل الذي ينشر ملف التعريف، والمُمرّر TCP فقط لن يحمل UDP إطلاقًا. تحقق من الناقل الذي يطلبه ملف التعريف قبل أن تستنتج أن الواجهة الأمامية غير ذات صلة.
تمرير TLS لتدفق واحد ترتيب ضيق. لا يوفر تمرير UDP، ولا يعيد إنتاج سلوك تمرير الخدمات لدى البرنامج الخفي نفسه على 443. إذا كانت واجهتك الأمامية تفعل أحد هذين الأمرين فبيّن أيهما، لأن العلاج يختلف.
علاجات تبقى ضيقة
أقل فحص إزعاجًا هو إنشاء ملف تعريف مدعوم جديد لحساب اختبار والاتصال عبر نقطة النهاية الأصلية المقصودة بمتطلبات المصادقة نفسها. إذا نجح ذلك ولم ينجح الملف القديم المحتفظ به، فقد فصلت الملف عن الخادم وعن الوكيل في خطوة واحدة.
توزيع ملف تعريف مقفل بالمستخدم يزيل اعتماد الإقلاع القديم بالكامل، لأنه لا يوجد تبادل لملف تعريف مؤقت يمكن أن يفشل. يجب أن يصدر للمستخدم المقصود، ولا يُنسخ أبدًا من مسؤول، وهو يغير ما يُصرح للعميل بفعله، لذا تعامل معه كقرار سياسة لا كحل التفافي.
ثم أصلح تخطيط النشر بحيث يوجد كل مسار مطلوب: مسار الويب للتنزيلات واستخدام البوابة، ومسار الـ VPN الأصلي على الناقل الذي تتوقعه ملفات التعريف. أبقِ عمل الوكيل في طبقة واحدة. النفق العامل المقفل بالمستخدم يثبت أن ذلك المسار يعمل؛ ولا يثبت أن كل ترتيب وكيل يدعم كل جيل، وفشل إقلاع قديم لا يدين الصيغة الأحدث.
- حدد جيل الملف قبل لمس الوكيل.
- حدد ما إذا كان الفشل يحدث قبل النفق أو داخله.
- أكد ما تنهيه الواجهة الأمامية: HTTP أو تدفق TCP أو UDP.
- اختبر ملف تعريف صادرًا حديثًا مقابل نقطة النهاية الأصلية مع بقاء السياسة دون تغيير.