يرفض الهاتف الاتصال ويطبع No trusted RSA public key found for vpn.example.net، بينما تعمل شهادة البوابة نفسها من حاسوب محمول على الشبكة ذاتها. الخطوة المغرية هي إعادة إصدار الشهادة. قبل ذلك حدِّد أي الأعطال الثلاثة لديك، لأن واحدًا منها فقط يتعلق بمحتوى الشهادة: سلسلة غير مكتملة، أو تعارض في الهوية، أو مفتاح أو توقيع غير مدعوم، ولكل منها إصلاح مختلف.

ثلاثة أعطال خلف رسالة واحدة

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

What you seeWhat it points toFirst move
Chain stops after the leaf in the daemon logintermediate not loaded or not sentload the intermediate as CA material
Chain validates, name differs from the profileidentity mismatchfix the profile name or the certificate SAN
Chain validates, handshake still failskey or signature not acceptedcompare key type against the device

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

قرِّر أولًا: هل وصلت السلسلة كاملة؟

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

افحص ما تحتفظ به الخدمة بـ swanctl --list-certs في نشر swanctl، أو ipsec listcerts مع المشغّل الأقدم. يجب أن تظهر الوسيطة كشهادة CA وفوقها الجذر. إن كانت غائبة فلن يساعد أي خيار في العميل؛ وإن كانت موجودة فانتقل إلى السؤال التالي.

ثم افحص ما إذا كانت ستُرسل. يوثّق مرجع swanctl.conf الخيار send_cert، حيث يرسل الافتراضي ifasked الشهادات فقط عندما يطلب النظير، بينما يرسل always دائمًا. المكافئ القديم هو leftsendcert=always في ipsec.conf. هذا الإعداد يتحكم بالإرسال لا بالتوفر، لذا لا يعوّض وسيطة لم تحمّلها الخدمة أبدًا.

إن كانت السلسلة قصيرة، حمّل الوسيطة حيث تبحث الخدمة

ضع الوسيطة في دليل CA لا بجوار الورقة: /etc/ipsec.d/cacerts لإعداد ipsec.conf، و/etc/swanctl/x509ca لـ swanctl، أو المسار الذي تستبدله حزمتك. أعد تحميل الإعداد وأدرج الشهادات مرة أخرى. بعض الإصدارات ترسل أيضًا حزمة تحتوي السلسلة داخل ملف الورقة، لكن دليل CA هو الترتيب المحمول بين الإصدارات والحزم.

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

إن كانت السلسلة كاملة، توقف عن تعديل الشهادات

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

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

لا تثبّت الوسيطة كجذر مستخدم على الهاتف

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

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

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