Android VPN-də Keystore xətası: yenidən qeydiyyat, kilidin açılması, yoxsa təkrar cəhd?
Android keystore-un üç nəticəsi üç fərqli bərpa tələb edir. Tətbiqin yaddaşını təmizləməzdən əvvəl kilidin açılmasını, yenidən qeydiyyatı və provayderin təkrar cəhdini müqayisə edin.
Profil hələ də siyahıda görünür, sertifikat hələ də quraşdırılmış kimi göstərilir, amma qoşulma düyməsi yalnız «Keystore xətası» deyən bir mesajla uğursuz olur. Tətbiqin yaddaşını təmizləməzdən və ya telefonu təhvil verməzdən əvvəl hansı açar əməliyyatının uğursuz olduğunu müəyyənləşdirin. Üç nəticə eyni dialoqu yaradır və onlar üç fərqli hərəkətə cavab verir — bunlardan yalnız biri dağıdıcıdır. Müqayisə on dəqiqəyə dəyər, çünki səhv budaq saxlamaq istədiyiniz kimliyə başa gəlir.
Bir dialoq arxasında üç nasazlıq
Birincisi autentifikasiyadır. Açar mövcuddur və etibarlıdır, lakin ondan istifadə istifadəçinin mövcudluğunu sübut etməsini tələb edir — cihazın kilidinin açılması, biometrik və ya iş profili çağırışı. Kilidləmə müddəti, qeydiyyatdan keçmiş biometrik məlumatlar və ya profil vəziyyəti bu yaxınlarda dəyişibsə, açarın özü tamamilə qaydasında olduğu halda açarın istifadəsi uğursuz ola bilər.
İkincisi daimi etibarsızlaşdırmadır. Bəzi açar materialı kilidləmə üsulu sıfırlandıqda və ya biometrik qeydiyyat dəyişdikdə platforma siyasəti ilə etibarsızlaşdırılır, çünki onu qoruyan bağ artıq keçərli deyil. Açar bərpa oluna bilməz və təkrar cəhd bərpa planı deyil; kimlik onu verən qeydiyyat prosesi vasitəsilə əvəz edilməlidir.
Üçüncüsü provayder nasazlığıdır: keystore xidməti əməliyyatı indi tamamlaya bilmədi. Bu, bəzən təkrar cəhdə dəyən sinifdir və yeganə belə sinifdir.
| 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 |
Nəzərə alın ki, üçündən ikisi dağıdıcı deyil, birinin isə cihaz səviyyəsində heç bir həlli yoxdur. Onların heç biri telefonu silməklə həll olunmur, halbuki insanlar ilk növbədə bu addımı atır, çünki dialoq onlara başqa heç nə vermir.
Yenidən qeydiyyat, yoxsa məlumatların təmizlənməsi
Bu ikisi kənardan oxşar görünür, amma deyil. Yenidən qeydiyyat verən sistemdən yeni kimlik — bu cihaza bağlanmış təzə sertifikat və ya açar — istəyir və köhnəni təqaüdə çıxarır. Məlumatların təmizlənməsi isə tətbiqin saxlanmış vəziyyətini silir; bu, açarı silmədən ona olan istinadı silə bilər, ya da açarı silib onu yenidən yaratmaq üçün heç bir səlahiyyət qoymaya bilər.
Fərq vacibdir, çünki ixrac edilə bilməyən açarlar dizayn etibarilə daşınmazdır. Onlar cihazın keystore-unda, mövcud olan hansısa aparat və ya provayderin dəstəyi ilə yaşayır və rezerv ehtiyat nüsxəsinin götürüb bərpanın geri qaytardığı bir şey deyillər. Əgər yerləşdirmənin kimliyi ixrac edilə bilməyən açardırsa, bərpa kimi yenidən qeydiyyatı planlaşdırın və əvvəlcədən həmin qeydiyyatı almaq üçün təsdiqlənmiş yolunuz olduğunu təsdiqləyin — bəzi təşkilatlar bunun üçün xüsusi şəbəkə girişi tələb edir, bu da məhz sınıq VPN-in təmin etdiyi şey idi.
Yəni ardıcıllıq budur: dəstəklənən autentifikasiya yolunu sınayın, sonra açarın daimi etibarsız olub-olmadığını müəyyənləşdirin və kimliyi yalnız belədirsə əvəz edin. Yaddaşın təmizlənməsi sonuncu yerdədir — nəyin yenidən yaradılacağını bildikdən sonra, asan olduğu üçün birinci deyil.
Yalnız təkrar cəhdə dəyəni təkrar cəhd edin
Köhnə platforma versiyaları keystore xətalarını tək bir istisnada birləşdirirdi, buna görə də bir çox müştəri hər şeyi təkrar cəhd edir. API 33-dən etibarən istisna tipi struktur daşıyır: rəqəmsal xəta, keçici nasazlıq bayrağı və təkrar cəhd siyasəti. Müştəri tərtibatçısı üçün təkrar cəhd siyasəti yalnız keçici bayraq doğru olduqda məna kəsb edir; daimi etibarsızlaşdırmanın təkrar cəhd cədvəli yoxdur və onu döngədə döymək sadəcə batareyanı boşaldır və jurnalı doldurur.
Əgər müştərini yazmaq əvəzinə diaqnostika edirsinizsə, praktiki nəticə eynidir. Hər cəhddə eyni nasazlıqlar birdəfəlik qlitchi istisna edir, lakin daimi etibarsızlaşdırılmış açarı bir müddətdir əlçatmaz olan provayderdən ayırmır — provayderin kəsilməsi onuncu təkrar cəhddə də birincidəki kimi görünür. API 33-ün strukturlaşdırılmış sahələri olmadan təkrarı ikinci siqnal axtarmaq üçün səbəb kimi qəbul edin — xəta kodu, əgər build-iniz onu göstərirsə, operatorun statusu və ya eyni cihazda başqa açarın uğur qazanması — açarın öldüyünə dair sübut kimi deyil.
Səbəb zəncirini oxuyun, etiketi deyil
Tətbiqlər orijinal istisnanı bükür və interfeysdəki mehriban mətn çox vaxt budağı təyin edən yeganə sahəni gizlədir. Səbəb zəncirini və cəhdin zaman nişanını saxlayın: xarici istisna adətən əməliyyatı, səbəb isə açarın vəziyyətini adlandırır.
İki uğursuz tətbiqin nasaz telefonu sübut etdiyi qənaətinə müqavimət göstərin. Fərqli açarlar fərqli provayderlər və təhlükəsizlik səviyyələri ilə dəstəklənə bilər və hələ işləyən tətbiq eyni əməliyyatı ümumiyyətlə icra etməyə bilər — imza, deşifrə və açar attestasiyası eyni xidmətə fərqli sorğulardır. KeyStoreException sənədi daha yeni API səviyyələrindəki strukturlaşdırılmış sahələri təsvir edir və build-inizin həqiqətən nə bildirə biləcəyini yoxlamaq üçün yerdir.
Aparat nəticəsini dəstəkləyəcək şey çoxlarının güman etdiyindən dardır: eyni əməliyyat, eyni provayderdə, açar səviyyəsində deyil, provayder səviyyəsində xəta ilə müstəqil açarlar üzrə uğursuz olur. Bu, platformanın diaqnostikası üçün sualdır, cihaz partiyası haqqında dəstək forumu mövzusu üçün deyil.
Qərar verərkən nə qeyd etməli
Android build-ini, müştəri versiyasını, seçilmiş profili, uğursuz olan əməliyyatı və yaxınlarda nəyinsə dəyişib-dəyişmədiyini qeyd edin — əməliyyat sistemi yeniləməsi, kilid ekranı dəyişikliyi, yeni barmaq izi, yenidən qeydiyyat. Ardıcıllığı səbəbin sübutu kimi deyil, kontekst kimi qeyd edin; açar nasazlığından əvvəlki kilid dəyişikliyi inandırıcı korrelyasiyadır, nümayiş deyil.
Sonra müəyyən etdiyiniz budaq üzrə hərəkət edin. Keçici: kimliyi saxlayın, dəstəklənən təkrar cəhd yolundan istifadə edin. Autentifikasiya tələb olunur: dəstəklənən kilid açma axınını tamamlayın və dialoqu keçmək üçün onu söndürmək əvəzinə yerləşdirmənin tələb etdiyi kilid siyasətini saxlayın. Daimi etibarsız: kimliyi normal qeydiyyat yolu ilə əvəz edin və təqaüdə çıxarın.
Nəticəni təzə, icazəli bir bağlantıda, real resursa, server yoxlaması hələ də aktiv ikən sübut etməklə bitirin. Yalnız sertifikat yoxlamaları yumşaldılmış halda işləyən heç nə açar problemini həll etməyib — onu şəbəkə qatına köçürüb, orada sonra daha pis simptomlarla üzə çıxacaq.
- Üç budaq: autentifikasiya tələb edir, daimi etibarsız, provayderdə keçici.
- Yalnız üçüncüsü təkrar cəhddən faydalanır və yalnız öz təkrar cəhd siyasətinə uyğun.
- Əvəzedici qeydiyyat girişi bərpa edir; məlumatların təmizlənməsi bu seçimi aradan qaldırır.
- Təzə bağlantı və normal server kimlik yoxlamaları ilə təsdiqləyin.