Napaka keystore v Android VPN: znova vpisati, odkleniti ali poskusiti znova?

Profil je še vedno na seznamu, potrdilo se še vedno prikazuje kot nameščeno, gumb za povezavo pa odpove s sporočilom, ki pravi samo Napaka keystore in nič drugega. Preden izbrišete shrambo aplikacije ali telefon izročite, ugotovite, katera operacija s ključem ni uspela. Trije izidi ustvarijo isto pogovorno okno in se odzivajo na tri različna dejanja — le eno od njih je uničujoče. Primerjava je vredna desetih minut, ker napačna veja vas stane identitete, ki ste jo poskušali ohraniti.

Tri okvare za enim pogovornim oknom

Prva je overjanje. Ključ obstaja in je veljaven, a njegova uporaba zahteva, da uporabnik dokaže prisotnost — odklep naprave, biometrijo ali izziv delovnega profila. Če so se časovna omejitev zaklepa, vpisana biometrija ali stanje profila nedavno spremenili, lahko uporaba ključa odpove, čeprav je ključ sam povsem v redu.

Druga je trajna razveljavitev. Nekateri ključni materiali se razveljavijo s politiko platforme, ko se ponastavi način zaklepanja ali spremeni biometrična vpisava, ker vez, ki ga je varovala, ne velja več. Ključa ni mogoče popraviti in ponovni poskus ni načrt obnovitve; identiteto je treba zamenjati s postopkom vpisa, ki jo je izdal.

Tretja je okvara ponudnika: storitev keystore zdaj ni mogla dokončati operacije. To je razred, ki ga je včasih vredno ponoviti, in edini.

Opazite, da dve od treh nista uničujoči in ena na ravni naprave nima nobene rešitve. Nobene od njih ne reši brisanje telefona, kar je korak, ki ga ljudje naredijo prvega, ker jim pogovorno okno ne ponuja ničesar drugega.

Ponovni vpis proti brisanju podatkov

Od zunaj sta si podobna in nista. Ponovni vpis od izdajateljskega sistema zahteva novo identiteto — sveže potrdilo ali ključ, vezan na to napravo — in staro upokoji. Brisanje podatkov izbriše shranjeno stanje aplikacije, kar lahko odstrani sklic na ključ, ne da bi odstranilo ključ, ali pa odstrani ključ in vas pusti brez pooblastila, da ga znova ustvarite.

Razlika je pomembna, ker neizvozljivi ključi po zasnovi niso prenosljivi. Živijo v shrambi ključev naprave, ki jo podpira razpoložljiva strojna oprema ali ponudnik, in niso nekaj, kar varnostna kopija zajame in obnovitev povrne. Če je identiteta v uvedbi neizvozljiv ključ, računajte na ponovni vpis kot obnovitev in vnaprej potrdite, da imate odobreno pot do tega vpisa — nekatere organizacije zanj zahtevajo dostop do zasebnega omrežja, kar je natanko to, kar je zagotavljal pokvarjeni VPN.

Vrstni red je torej: poskusite podprto pot overjanja, nato ugotovite, ali je ključ trajno razveljavljen, in identiteto zamenjajte le, če je. Brisanje shrambe spada na konec, potem ko veste, kaj bo znova ustvarjeno, ne na začetek, ker je preprosto.

Ponavljajte samo to, kar je mogoče ponoviti

Starejše različice platforme so okvare keystore združile v eno samo izjemo, zato toliko odjemalcev ponavlja vse. Od API 33 vrsta izjeme nosi strukturo: številsko napako, zastavico prehodne okvare in politiko ponovnih poskusov. Za razvijalca odjemalca ima politika ponovnih poskusov smisel le, ko je zastavica prehodnosti resnična; trajna razveljavitev nima urnika ponovitev in udarjanje po njej v zanki le prazni baterijo in polni dnevnik.

Če diagnosticirate, namesto da pišete odjemalca, je praktična posledica enaka. Enake okvare pri vsakem poskusu izključujejo enkratno napako, ne ločijo pa trajno razveljavljenega ključa od ponudnika, ki je že nekaj časa nedosegljiv — izpad ponudnika je pri desetem poskusu videti natanko enako kot pri prvem. Brez strukturiranih polj API 33 imejte ponavljanje za razlog za iskanje drugega signala — kode napake, če jo vaša izgradnja razkrije, stanja operaterja ali uspeha drugega ključa na isti napravi — in ne za dokaz, da je ključ mrtev.

Berite verigo vzrokov, ne oznake

Aplikacije ovijejo izvirno izjemo in prijazni niz v vmesniku pogosto skrije edino polje, ki odloči vejo. Ohranite verigo vzrokov in časovni žig poskusa: zunanja izjema običajno poimenuje operacijo, vzrok pa poimenuje stanje ključa.

Ne nasedajte sklepu, da dva odpovedujoča se programa dokazujeta okvarjen telefon. Različne ključe lahko podpirajo različni ponudniki in ravni varnosti, program, ki še deluje, pa morda sploh ne izvaja iste operacije — podpis, dešifriranje in overitev ključa so različne zahteve do iste storitve. Referenca KeyStoreException opisuje strukturirana polja na novejših ravneh API in je mesto, kjer preverite, kaj vaša izgradnja lahko dejansko poroča.

Kar bi podprlo sklep o strojni opremi, je ožje, kot večina ljudi domneva: ista operacija, pri istem ponudniku, ki odpove pri neodvisnih ključih z napako na ravni ponudnika, ne ključa. To je vprašanje za diagnostiko platforme, ne za nit na podpornem forumu o seriji naprav.

Kaj zabeležiti, medtem ko se odločate

Zabeležite izgradnjo Androida, različico odjemalca, izbrani profil, operacijo, ki ni uspela, in ali se je nedavno kaj spremenilo — posodobitev OS, sprememba zaklepnega zaslona, nov prstni odtis, ponovni vpis. Zaporedje zapišite kot kontekst, ne kot dokaz vzroka; sprememba zaklepa pred okvaro ključa je verjetna korelacija, ne demonstracija.

Nato ravnajte po ugotovljeni veji. Prehodno: ohranite identiteto, uporabite podprto pot ponovitve. Potrebno overjanje: dokončajte podprti tok odklepanja in ohranite politiko zaklepanja, ki jo uvedba zahteva, namesto da bi jo onemogočili, da bi prišli mimo pogovornega okna. Trajno razveljavljeno: zamenjajte in upokojite identiteto z običajnim vpisom.

Na koncu dokažite izid na novi pooblaščeni povezavi do resničnega vira z vključenim preverjanjem strežnika. Kar deluje le ob sproščenih preverjanjih potrdil, ni odpravilo težave s ključem — premaknilo jo je v omrežno plast, kjer se bo pozneje pokazalo s slabšimi simptomi.

• Tri veje: potrebno overjanje, trajno razveljavljeno, prehodna okvara ponudnika.
• Le tretja ima korist od ponavljanja, in sicer le po svoji politiki ponovitev.
• Nadomestni vpis obnovi dostop; brisanje podatkov to možnost odstrani.
• Preverite z novo povezavo in običajnimi preverjanji identitete strežnika.