IKEv2 عنوان الخادم مقابل الهوية: ما يتحقق منه العميل بالفعل

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

قم بفحصها بهذا الترتيب وتوقف عند عدم التطابق الأول، لأن عمليات التحقق اللاحقة تفترض اجتياز عمليات التحقق السابقة.

أولاً، ما هي القيمة التي يمثلها العنوان؟

عنوان الاتصال هو ما يطلبه العميل: عنوان IP، أو اسم DNS الذي يتحول إلى واحد، أو واجهة أمامية متوازنة التحميل. هذه هي معلومات النقل وليس أكثر. يتم تثبيت الهوية في حمولة معرف IKEv2 ومن ثم تتم مطابقتها مع شهادة النظير. لا يصبح اسم DNS في مربع العنوان هوية متوقعة، ولا يصبح عنوان IP الأولي هوية لمجرد أن المقبس متصل به.

في مصطلحات strongSwan، العنوان هو right أو left، والهوية المتوقعة هي rightid أو leftid، وهذا ما تصفه وثائق التكوين IKEv2 . إذا قمت بتحرير العنوان فقط، فقد قمت بتكوين نصف الزوج.

ثانيا: ما يمكن أن تثبته الشهادة

الهوية لها نوع، ويجب أن تحمل الشهادة اسمًا مطابقًا لها. يتم استيفاء هوية DNS من خلال إدخال dNSName في ملحق الاسم البديل للموضوع؛ تحتاج هوية IP إلى إدخال iPAddress. الشهادة الصادرة لـ vpn.example.com لا تثبت شيئًا عن العنوان الحرفي 203.0.113.10، والشهادة الصادرة لهذا العنوان لا تثبت شيئًا عن الاسم. وبالتالي فإن إعادة الإصدار لاسم مختلف لا تعد بديلاً مباشرًا، حتى عند إعادة استخدام نفس المفتاح وCA.

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

ثالثًا، كيف يذكر كل عميل توقعاته

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

في strongSwan يكون التوقع صريحًا: قم بتعيين rightid على الهوية التي يقدمها الخادم بالفعل، والتي قد تختلف عن اليمين. يؤدي تعيينه إلى %any إلى قبول ما يقدمه النظير وإزالة الشيك الذي تحاول الاحتفاظ به تمامًا.

رابعاً، قم بفصل تسجيل دخول المستخدم عن هوية النظير

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

يجب أن يذكر التقرير المصحح كلاً من: الهوية التي توقعها العميل، والهوية التي قدمها الخادم، وإدخالات الشهادة SAN.

خامسا، قم بتغييره من خلال قناة تم التحقق منها

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

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