iPhone IKEv2 إلى RouterOS: أي مُعرّف يوضع وأين
أربعة ادعاءات منفصلة تحدّد نفق IKEv2 على iOS: العنوان المطلوب، وهوية الخادم المتوقعة، وهوية العميل المدّعاة، ومواد الشهادة.
الوصول إلى بوابة MikroTik يحسم نصف النقل فقط في نشر IKEv2، ولا شيء غير ذلك. بعد ذلك تحدّد أربعة ادعاءات منفصلة ما إذا كان النفق سيتشكّل: العنوان الذي يطلبه الهاتف، وهوية الخادم التي يتوقعها، والهوية التي يدّعيها لنفسه، ومواد الشهادة التي تدعم ذلك الادعاء. افحصها بهذا الترتيب، وتوقف عند أول واحد لا يتوافق مع ما تعرضه البوابة. كل واحد منها قابل للتعديل في مكان مختلف، ولهذا فإن التعديل الخاطئ ينقل الفشل عادةً بدلاً من إصلاحه.
| Setting | What it decides | What it has to agree with |
|---|---|---|
| Remote address | where IKE packets are sent | a reachable name or address for the gateway |
| Remote Identifier | which server identity is expected | the gateway certificate name and the peer identity RouterOS presents |
| Local Identifier | who the phone claims to be | the client certificate name and the RouterOS identity entry |
| Certificate payload | trust plus proof of key possession | the issuing chain and a usable client private key |
افحص حقول الملف الشخصي بالترتيب الذي يستخدمه التبادل
العنوان البعيد هو وجهة أول حزمة IKE ولا شيء أكثر. مُعرّف البعيد هو ما يتوقع الهاتف أن تثبت البوابة أنها هي، وهو اسم وليس مساراً. ملء الاثنين بنفس اسم المضيف ينجح عندما تحمل شهادة البوابة ذلك الاسم، ويفشل بطريقة تبدو كمشكلة توجيه عندما لا تحمله. اقرأ الملف الشخصي كسلسلة ادعاءات لا كقائمة حقول يجب ملؤها.
مُعرّف المحلي هو ادعاء الهاتف عن نفسه، ويجب أن يكون اسماً يقبله إدخال الهوية في RouterOS للشهادة العميلة التي يقدمها الهاتف. إذا اختلف الاثنان، ترفض البوابة الاتصال بعد أن تُثبت الشهادة نفسها، وتبدو السجلات كمشكلة تصريح لا كمشكلة تسمية.
افحص المعرّفات مقابل ما تعرضه البوابة
إدخال النظير في RouterOS المُعدّ للمصادقة بالشهادة يعرض شهادته الخاصة، وتُستمد هويته من تلك الشهادة ما لم تُعدّ خلاف ذلك. إذا كان المُعرّف البعيد في الهاتف يسمّي اسم DNS للبوابة، فتحتاج شهادة البوابة إلى ذلك الاسم في موضع يقبله الهاتف، وعادةً ما يكون الاسم البديل للموضوع. الشهادة الصادرة باسم شائع مختلف ستفشل في التحقق حتى لو كان المفتاح والسلسلة سليمين.
يمكن أن تحمل ملفات Apple المُدارة أيضاً قيداً على اسم الشهادة يُقيَّم بالإضافة إلى حقول المُعرّف. افحص الحمولة بدلاً من استنتاج اسم التحقق من ما تعرضه شاشة الإعدادات، لأن الاثنين ليسا الإعداد نفسه.
افحص أن الشهادة العميلة مفتاح، وليست مجرد مرساة ثقة
استيراد شهادة CA يمنح الهاتف شيئاً يتحقق به من البوابة. لكنه لا يمنح الهاتف هوية عميلة، والمصادقة بالشهادة تحتاج إلى شهادة الورقة العميلة ومفتاحها الخاص معاً عبر مسار التسجيل المعتمد. ملف PKCS#12 مبني بدون المفتاح الخاص ينتج ملفاً شخصياً يُثبَّت بسلاسة ولا يصادق على شيء.
تحتاج الورقة العميلة أيضاً إلى هوية يتوقعها جانب RouterOS، ما يعني أن الموضوع أو الاسم البديل للموضوع يجب أن يتطابق مع إعداد الهوية المقابل. إصدار شهادات العميل والخادم من CA واحدة يجعل السلسلة مريحة ولا يجعل الورقتين قابلتين للتبادل.
افحص أن سياسة RouterOS تقبل ذلك الاسم
على البوابة، يضبط إدخال النظير وضع التبادل وطريقة المصادقة، ويربط إدخال الهوية الهوية البعيدة المقبولة بشهادة وبالسياسة التي تتبعها. في RouterOS v7 يُعبَّر عن هذا الاقتران عبر إدخالات النظير والهوية في IPsec، مثلاً نظير IKEv2 مع auth-method=digital-signature. افحص محتويات القائمة الفعلية في الإصدار المثبَّت لديك بدلاً من دليل مكتوب لإصدار أقدم.
هنا أيضاً يكون إصلاح عدم التطابق أرخص، لأن البوابة تستطيع أن تخبرك بالهوية التي استلمتها والهوية التي أرادتها. توسيع الهوية المقبولة لإسكات الخطأ يزيل الربط الذي جعل النشر ذا معنى.
افحص أي مرحلة فشلت قبل أن تعدّل أي شيء
اقرأ المحاولة على الطرفين وصنّفها قبل تغيير أي اقتراح. عدم تطابق الاقتراح، ومفتاح توقيع مفقود، ومُصدر غير موثوق، ومُعرّف نظير خاطئ، وتصريح عميل مرفوض — كلها تبدو من الهاتف كنفق ميت، ولكل منها مسؤول مختلف. تغيير الإعدادات الخمسة كلها دفعة واحدة يضمن ألا تتعلم شيئاً من النتيجة.
سجّل الهوية المعروضة، والهوية المتوقعة، ومُصدر الشهادة ورقمها التسلسلي، واسم السياسة ذا الصلة، مع إبقاء المفاتيح الخاصة وأسرار الملف الشخصي خارج ذلك السجل. بعد نجاح المصادقة، اختبر خدمة خاصة وردّها، لأن تعيين العناوين والمحددات وDNS وسياسة الوصول ما زالت بحاجة إلى العمل بعد انتهاء تبادل IKE.