هويتان في تسجيل دخول IKEv2 واحد: الجهاز أولاً ثم المستخدم

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

العَرَض: فشل بعد أول دليل ناجح

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

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

ما تضيفه الإضافة وما لا تضيفه

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

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

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

EAP-TLS شكل ثالث، وهو أيضاً ليس هذا. هناك تُقدَّم شهادة عميل داخل طريقة EAP، فيكمل العميل تحقق IKE واحداً. وقد تبدو بيانات الاعتماد مطابقة لحالة الجولات المتعددة بينما يحمل البروتوكول جولة واحدة بدل جولتين. لهذا يفشل تصميم منسوخ من نشر EAP-TLS عند النقطة التي يُتوقع فيها الدليل الثاني.

الملف نفسه يُقرأ بشكل مختلف على البوابة

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

موضع القسم يحدد ترتيبه ما لم يتجاوزه رقم جولة. لذا تصف أقسام local أو remote الإضافية جولات إضافية لا بدائل، ورقم الجولة الصريح في مرجع swanctl.conf موجود تحديداً لجعل ذلك الترتيب متعمداً. وبدونه، يغيّر نقل كتلة السلوك. ولهذا أيضاً يمكن لتكوينين يبدوان متكافئين على الورق أن يعملا بترتيبين متعاكسين.

تنتج قاعدة الترتيب تلك نمط الفشل الجدير بالتذكّر. كتلة remote ثانية ليست خياراً آخر مقبولاً؛ إنها طلب ثانٍ، ولهذا تتصرف سياسة تُقرأ كإما/أو كـ ثم/و. قد تقبل سياسة البوابة شهادة الجهاز المسجّل ثم تشترط مبادلة EAP لذلك المستخدم، بهذا الترتيب.

ميّز الجولات عن العوامل المستقلة

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

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

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

اكتب قاعدة الاقتران واختبر حالات الرفض

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

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

swanctl --list-conns
swanctl --list-sas

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