تسجيل الدخول إلى OpenConnect يهبط على الصفحة الخطأ؟ تحقّق من المسار أولًا

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

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

ما يرسله العميل قبل أن ترى استمارة

مع عنوان مثل https://vpn.example.net/partners، يكون أول فعل للعميل طلب HTTPS إلى ذلك المسار لا إلى المضيف المجرّد. وما يعود عادةً إعادة توجيه إلى نقطة الدخول، أو الاستمارة نفسها. والعميل الذي يُعطى vpn.example.net فقط يبدأ من صفحة الهبوط الافتراضية أيًّا كانت، وقد تكون بوابة أخرى أو قائمة مجموعات أخرى أو صفحة تتوقع بروتوكولًا مختلفًا تمامًا. والفرق ظاهر في ترويسات الاستجابة قبل كتابة أي بيانات اعتماد بوقت طويل.

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

مدخلان يبدوان قابلين للتبادل وليسا كذلك

يكشف OpenConnect مسار HTTPS الأولي عبر --usergroup، ويعامل دليل الاستخدام عنوان URL كاملًا يحمل ذلك المسار كالطلب نفسه مكتوبًا بصيغة أخرى. أما --authgroup فهو خيار منفصل: يختار مدخلًا من القائمة التي تعرضها البوابة داخل استمارة الدخول. بعض البروتوكولات تسمّي ذلك المدخل مجموعة، وبعضها يسمّيه نطاقًا أو بوابة، وهنا بالضبط يختلط الأمر بين العلمين.

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

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

لماذا يغيّر تقليم المسار النتيجة

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

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

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

أكّد نقطة الدخول قبل تعديل أي شيء آخر

اقرأ الترويسات الخاصة بالمسار الذي أُعطي لك. طلب مثل curl -sS -o /dev/null -D - https://vpn.example.net/partners يطبع سطر الحالة وأي ترويسة Location دون اتباع إعادة التوجيه. ورمز 302 الذي يشير إلى نقطة دخول مسماة يؤكد وجود المسار ويبيّن إلى أين يذهب؛ أما 404 فيعني أن عنوان المشغّل قديم.

ثم أعد إنتاج نقطة الدخول نفسها في العميل المعتمد، مثل openconnect --usergroup=partners vpn.example.net، وراقب أي استمارة تظهر. إن كانت الاستمارة صحيحة والنفق لا يزال يفشل، فالمسار لم يكن المشكلة قط، والمحطة التالية هي السياسة أو التوجيه.

سجّل اسم المضيف والمنفذ والبروتوكول ومسار الدخول واختيار الاستمارة كخمسة حقول منفصلة في التذكرة. تلك القائمة هي ما يتيح للمهندس التالي التمييز بين خادم لا يمكن الوصول إليه ورفض TLS واختيار مرفوض ونفق ارتفع دون المسارات التي احتاجها.