تبادل IKEv2 ينجح ثم تفشل المصادقة: أين يتوقف

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

الفحص 1: اقرأ المرحلة لا الرسالة

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

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

الفحص 2: أي هوية جرى فحصها

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

بمصطلحات strongSwan هذا هو rightid على العميل، وهوية البوابة نفسها على الطرف الآخر، وأي اختلاف يفشل قبل أن يُطرح EAP أصلًا.

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

الفحص 3: إذا كان EAP مستخدمًا

يجب أن يتفق العميل والخادم على طريقة مدعومة، وأن يقبل النظام الخلفي الهوية المقدمة.

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

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

الفحص 4: ما يحدث بعد تسجيل دخول ناجح

بعد اكتمال IKE_AUTH، يحدد تفاوض CHILD_SA أي محدّدات حركة تُثبّت، وهنا قد ينجح الاتصال ولا يمرر شيئًا.

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

الفحص 5: ما الذي تسلمه للدعم

الجدول الزمني المنقّح والرفض الدقيق أثمن من تصدير تشخيصي كامل، وقد يحتوي التصدير على مفاتيح خاصة أو بيانات اعتماد لا ينبغي مشاركتها.

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