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

اتجاها تحقق في تبادل واحد

يبني IKEv2 قناة تحكم على مرحلتين. تتفاوض الأولى على الخوارزميات والمفاتيح، وتنقل الثانية، IKE_AUTH، حمولة AUTH واحدة من كل طرف مع هوية ذلك الطرف. الحمولة توقيع أو MAC محسوب على التبادل، ويجري التحقق منه مقابل شيء يثق به المتلقي مسبقا.

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

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

MaterialRoleWhat it cannot do
User certificate plus its private keyProves possession of the enrolled client identityEstablish that the gateway is the right one
Trusted CA certificateValidates the gateway chain under the intended identity checksProve the client's identity to the gateway
Expected gateway identityPins which server the phone acceptsGrant that user access to every private resource

ماذا يطلب منشئ ملف Android

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

اقرأ هذا التوقيع بتمعن، فهو يختصر الآلية السابقة. لا يوجد حقل للمفتاح الخاص في طريقة اسم المستخدم وكلمة المرور، ولا حقل لمرساة ثقة البوابة في طريقة PSK، لأن تلك الطرق تثبت أمورا مختلفة. ولصق كلمة مرور في حقل شهادة ينتج ملفا يفشل عند IKE_AUTH برسالة لا تذكر أيا من الاثنين.

نوع المفتاح الخاص الموثق لطريقة التوقيع الرقمي هو RSA. والقائمة الموسومة IPsec أو شهادة لا تعني دعم ECDSA، والملف المبني على هذا الافتراض يفشل عند واجهة المنصة قبل أن يدخل الشبكة أصلا.

لماذا لا تكفي شهادة مستخدم عامة وحدها

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

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

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

مراسي الثقة تخص التطبيق لا الهاتف

تثبيت جذر في مخزن المستخدم لا يجعل كل تطبيق على Android يثق به: فمنذ Android 7 على التطبيق أن يختار ذلك عبر إعداد أمان الشبكة، وقبل ذلك الإصدار كانت الجهات المثبتة من المستخدم مقبولة على نطاق أوسع بكثير. وقد يختلف إعداد الثقة بين تطبيق وآخر، وقد لا ينظر عميل VPN يدير مادة ثقته بنفسه إلى مخزن المستخدم إطلاقا. لذلك قد يعمل ملف الجهة نفسه في عميل ويبدو متجاهلا في آخر.

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

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

اختر الوضع ثم الملفات

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

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

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

مقالات ذات صلة