strongSwan EAP: هوية IKE مقابل اسم AAA المتوقع

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

اتصال واحد وهوية خادم اثنتان

الهوية الأولى تنتمي إلى تبادل IKE. يتصل العميل بعنوان ويتوقع أن يثبت النظير هوية معينة، وعادةً يكون الاسم في شهادة البوابة.

الهوية الثانية تنتمي إلى EAP. مع PEAP أو TTLS، يبني العميل نفق TLS إلى خادم المصادقة داخل IKE SA، ويقدّم ذلك الخادم الداخلي شهادته الخاصة. وعندما يكون الجزء الخلفي مضيفاً منفصلاً، يختلف اسمه عن اسم البوابة. والعميل الذي يفحص الاسم الأول فقط يقبل ما يؤكده الاسم الثاني. أما العميل المضبوط باسم واحد في الموضعين فيفشل بمجرد أن يختلف الاثنان فعلاً.

كلا الاسمين يأتي من إعداد المشغّل لا من الشهادة التي تجعل الخطأ يختفي. وسؤال المشغّل عن تفاصيل النشر أسرع من تخمين اسمَي مضيف.

أي حقل ينتمي إلى أي طبقة

في swanctl، العنوان وهوية IKE إعدادان منفصلان، وهوية EAP ثالث.

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

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

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

لماذا يسكن aaa_id تحت local

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

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

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

واجهات أمامية لا تستطيع التعبير عن الانفصال

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

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

البديل ليس شيئاً يُبتكر على العميل. اطلب الترتيب المدعوم كتابةً، ثم احتفظ بتلك الإجابة مع الملف.

ميّز عدم تطابق الهوية من شهادة منتهية

عدم تطابق الاسم وشهادة منتهية فشلان مختلفان، والسجل يميّز بينهما. اقرأ الرسالة قبل أن تقرر أي حقل تغيّر.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

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