خطأ Keystore على VPN بنظام Android: هل تعيد التسجيل أم تفتح القفل أم تعيد المحاولة؟
ثلاث نتائج لمخزن المفاتيح على Android تحتاج إلى ثلاثة علاجات مختلفة. قارن فتح القفل وإعادة التسجيل وإعادة المحاولة عند المزوّد قبل مسح مساحة تخزين التطبيق.
لا يزال الملف الشخصي مدرجًا، ولا تزال الشهادة تظهر كأنها مثبّتة، ويفشل زر الاتصال برسالة تقول «خطأ Keystore» ولا شيء غير ذلك. قبل أن تمسح مساحة تخزين التطبيق أو تسلّم الهاتف، حدّد أي عملية مفاتيح فشلت. ثلاث نتائج تنتج الحوار نفسه، وهي تستجيب لثلاثة إجراءات مختلفة — واحد منها فقط مدمّر. المقارنة تستحق عشر دقائق لأن الفرع الخطأ يكلّفك الهوية التي كنت تحاول الحفاظ عليها.
ثلاثة أعطال خلف حوار واحد
الأول هو المصادقة. المفتاح موجود وصالح، لكن استخدامه يتطلب أن يثبت المستخدم حضوره — فتح قفل الجهاز، أو بصمة حيوية، أو تحدٍّ من ملف العمل. إذا تغيّر مؤخرًا مهلة القفل أو البصمات المسجّلة أو حالة الملف الشخصي، فقد يفشل استخدام المفتاح بينما يكون المفتاح نفسه سليمًا تمامًا.
الثاني هو الإبطال الدائم. بعض مواد المفاتيح تُبطلها سياسة المنصة عند إعادة تعيين طريقة القفل أو تغيّر تسجيل البصمات، لأن الارتباط الذي كان يحميها لم يعد قائمًا. لا يمكن إصلاح المفتاح، وإعادة المحاولة ليست خطة تعافٍ؛ يجب استبدال الهوية عبر عملية التسجيل التي أصدرتها.
الثالث هو عطل عند المزوّد: لم تتمكن خدمة مخزن المفاتيح من إتمام العملية الآن. هذه هي الفئة التي تستحق أحيانًا إعادة المحاولة، وهي الوحيدة.
| Failure | What it means | What recovers it | What does not |
|---|---|---|---|
| User not authenticated | Key needs a presence check | Supported unlock or authorization flow | A VPN account password reset |
| Key permanently invalidated | Binding is gone; key unusable | Replacement enrollment for that identity | Retrying, rebooting, reinstalling the client |
| Transient provider error | Service could not complete now | The provider's documented retry path | Clearing app data |
لاحظ أن اثنتين من الثلاث غير مدمّرتين، وأن واحدة لا حل لها على مستوى الجهاز إطلاقًا. ولا واحدة منها يعالجها محو الهاتف، وهو الخطوة التي يبدأ بها الناس لأن الحوار لا يمنحهم شيئًا آخر يتصرفون بناءً عليه.
إعادة التسجيل مقابل مسح البيانات
هاتان تبدوان متشابهتين من الخارج وليستا كذلك. إعادة التسجيل تطلب من النظام المُصدِر هوية جديدة — شهادة أو مفتاحًا جديدًا مرتبطًا بهذا الجهاز — وتُقاعد القديمة. أما مسح البيانات فيحذف الحالة المخزّنة للتطبيق، وقد يزيل الإشارة إلى المفتاح دون إزالة المفتاح، أو قد يزيل المفتاح ويتركك بلا صلاحية لإعادة إنشائه.
الفرق مهم لأن المفاتيح غير القابلة للتصدير غير قابلة للنقل بحكم التصميم. فهي تعيش في مخزن مفاتيح الجهاز مدعومة بأي عتاد أو مزوّد متاح، وليست شيئًا تلتقطه نسخة احتياطية وتعيده عملية استعادة. إذا كانت هوية النشر مفتاحًا غير قابل للتصدير، فاعتمد إعادة التسجيل كخطة التعافي، وتأكد مسبقًا من وجود مسار معتمد للحصول على ذلك التسجيل — فبعض المؤسسات تشترط وصولًا إلى شبكة خاصة لذلك، وهو بالضبط ما كانت توفره شبكة VPN المعطوبة.
إذن فالترتيب هو: جرّب مسار المصادقة المدعوم، ثم حدّد ما إذا كان المفتاح مبطلًا بشكل دائم، ولا تستبدل الهوية إلا إذا كان كذلك. مسح التخزين يأتي أخيرًا، بعد أن تعرف ما سيُعاد إنشاؤه، لا أولًا لأنه سهل.
أعد المحاولة فقط لما يمكن إعادة محاولته
إصدارات المنصة الأقدم كانت تدمج أخطاء مخزن المفاتيح في استثناء واحد، ولهذا يعيد كثير من العملاء محاولة كل شيء. من API 33 يحمل نوع الاستثناء بنية: خطأ رقمي، وعلم فشل عابر، وسياسة إعادة محاولة. بالنسبة لمطوّر العميل، لا تكون سياسة إعادة المحاولة ذات معنى إلا عندما يكون علم العابر صحيحًا؛ والإبطال الدائم ليس له جدول إعادة محاولة، وطرقه في حلقة لا يفعل سوى استنزاف البطارية وملء السجل.
إذا كنت تشخّص بدلًا من كتابة العميل، فالنتيجة العملية هي نفسها. الأعطال المتطابقة في كل محاولة تستبعد خللًا عارضًا واحدًا، لكنها لا تفصل مفتاحًا مبطلًا بشكل دائم عن مزوّد كان غير متاح لفترة — انقطاع المزوّد يبدو تمامًا كما هو في المحاولة العاشرة وكما في الأولى. بدون حقول API 33 المهيكلة، عامل التكرار كسبب للبحث عن إشارة ثانية — رمز الخطأ إن كان بناءك يكشفه، أو حالة المشغّل، أو نجاح مفتاح آخر على الجهاز نفسه — لا كدليل على أن المفتاح ميت.
اقرأ سلسلة السبب، لا التسمية
تغلّف التطبيقات الاستثناء الأصلي، وكثيرًا ما يخفي النص الودود في الواجهة الحقل الوحيد الذي يحدد الفرع. احتفظ بسلسلة السبب وبالطابع الزمني للمحاولة: فالاستثناء الخارجي يسمّي العملية عادةً، والسبب يسمّي حالة المفتاح.
قاوم الاستنتاج بأن تطبيقين فاشلين يثبتان عيبًا في الجهاز. فمفاتيح مختلفة قد يدعمها مزوّدون ومستويات أمان مختلفة، وقد لا يمارس تطبيق ما زال يعمل العملية نفسها إطلاقًا — فالتوقيع وفك التشفير وإثبات المفتاح طلبات مختلفة إلى الخدمة نفسها. أما مرجع KeyStoreException فيصف الحقول المهيكلة في مستويات API الأحدث، وهو المكان الذي تتحقق فيه مما يستطيع بناءك الإبلاغ عنه فعلًا.
ما يدعم استنتاجًا بعطل عتاد أضيق مما يفترض معظم الناس: العملية نفسها، على المزوّد نفسه، تفشل عبر مفاتيح مستقلة بخطأ على مستوى المزوّد لا على مستوى المفتاح. ذلك سؤال لتشخيص المنصة، لا لموضوع في منتدى دعم عن دفعة أجهزة.
ما الذي تسجّله أثناء قرارك
سجّل بناء Android، وإصدار العميل، والملف الشخصي المحدد، والعملية التي فشلت، وما إذا كان أي شيء قد تغيّر مؤخرًا — تحديث نظام، أو تغيير شاشة القفل، أو بصمة جديدة، أو إعادة تسجيل. سجّل التتابع كسياق لا كدليل على السبب؛ فتغيّر القفل قبل فشل المفتاح ارتباط محتمل، لا برهان.
ثم تصرّف وفق الفرع الذي حددته. عابر: احتفظ بالهوية واستخدم مسار إعادة المحاولة المدعوم. مصادقة مطلوبة: أكمل تدفق فتح القفل المدعوم واحتفظ بسياسة القفل التي يتطلبها النشر بدلًا من تعطيلها لتجاوز حوار. مبطل بشكل دائم: استبدل الهوية وأحلها عبر التسجيل العادي.
اختم بإثبات النتيجة على اتصال مصرّح به جديد، إلى مورد حقيقي، مع بقاء تحقق الخادم مفعّلًا. فأي شيء لا يعمل إلا بتحقيقات شهادات مخفّفة لم يصلح مشكلة المفتاح — بل نقلها إلى طبقة الشبكة، حيث ستظهر لاحقًا بأعراض أسوأ.
- ثلاثة فروع: تحتاج مصادقة، أو مبطل دائمًا، أو عابر عند المزوّد.
- الفرع الثالث وحده يستفيد من إعادة المحاولة، ووفق سياسة إعادة المحاولة الخاصة به فقط.
- إعادة التسجيل بالاستبدال تعيد الوصول؛ ومسح البيانات يزيل الخيار.
- تحقّق باتصال جديد وتحقيقات هوية خادم عادية.