VPN desada a Android: quin secret podeu recuperar?
Un telèfon que es torna a connectar sense demanar contrasenya no n'emmagatzema cap que pugueu copiar. Compareu les quatre credencials i la recuperació que necessita cadascuna.
El telèfon es torna a connectar a la VPN cada matí sense demanar res. Això implica que la credencial és en algun lloc. Normalment no ho és, almenys no en una forma que pugueu llegir i escriure en un dispositiu nou.
El que té el telèfon és autoritat per connectar-se. El que voleu és un secret que pugueu portar amb vosaltres, i aquestes són propietats diferents que casualment produeixen el mateix comportament a la pantalla.
Abans de restablir res, identifiqueu quin dels quatre tipus de secret falta realment, perquè cadascun té un propietari diferent i una recuperació diferent.
Una connexió que funciona no és una contrasenya desada
Una aplicació que es reconnecta en silenci pot tenir una contrasenya, un testimoni de sessió, una referència a un certificat o res més que una clau lligada al dispositiu que no pot exportar. Les quatre produeixen la mateixa experiència d'usuari i cap no és intercanviable.
Una fila de punts en un camp de configuració és una decisió de representació, no una prova. Algunes aplicacions desen realment una contrasenya recuperable i ofereixen revelar-la o exportar-la; altres prenen un testimoni d'un flux d'inici de sessió únic i mai no veuen la contrasenya.
Així que la primera pregunta no és on és el fitxer. És quin tipus d'autoritat va rebre l'aplicació, i aquesta resposta ve del proveïdor, no del dispositiu.
Quatre secrets, quatre recuperacions
Feu coincidir la vostra situació amb una fila abans de contactar amb algú, perquè la petició canvia completament segons quin sigui el cas.
| What is missing | Who can restore it |
|---|---|
| Account password used with a username | The identity provider, through a reset |
| Password protecting a private key or PKCS#12 package | Nobody, if it is forgotten; a fresh profile and key are issued instead |
| Session token or SSO session | Nobody; sign in again to obtain a new session |
| Reference to a certificate or key held on the device | The administrator, by enrolling the new device |
La segona fila és la que enganxa més gent. Una contrasenya d'importació PKCS#12 protegeix material de clau i no té relació amb l'inici de sessió del compte, així que restablir la contrasenya del compte no recupera res. Si la contrasenya del paquet s'ha perdut de veritat, la solució és reemetre'l.
La quarta fila explica molts fils de suport confusos. El perfil pot referenciar una credencial al magatzem de claus de la plataforma en lloc de contenir una còpia portàtil, i en aquest cas no hi ha res al perfil per extreure ni tan sols en principi.
Per què copiar les dades de l'aplicació normalment falla
La recepta antiga és extreure el directori de dades de l'aplicació i llegir-ne la configuració. A l'Android actual la recepta té dos problemes independents.
El primer és la política de còpia de seguretat. Android 12 va restringir les dades d'aplicacions exportades pel camí antic adb backup per a aplicacions dirigides a API 31 o posterior, i les aplicacions poden excloure les dades de la còpia de seguretat del tot. Un procediment escrit per a un dispositiu antic no és un mètode de recuperació universal per a un d'actual.
El segon és el magatzem de claus. Les claus generades allà poden ser no exportables i lligades al maquinari, com descriu la documentació d'Android Keystore. Copiar un blob xifrat no copia la clau que el desxifra, així que un directori restaurat pot contenir una credencial que el dispositiu nou mai no podrà fer servir.
Cap dels dos problemes no és un error que calgui evitar. Tots dos són la plataforma fent el que va ser dissenyada per fer, i tractar-los com a obstacles sol acabar amb un telèfon rootejat i sense contrasenya.
Passeu a un telèfon de substitució deliberadament
Feu primer el que està suportat. Si el proveïdor ofereix una exportació que inclou explícitament les credencials que necessiteu, feu-la servir i verifiqueu el resultat al dispositiu nou abans d'esborrar el vell. Si no ho fa, demaneu un perfil o una inscripció nous, que és el camí normal per als serveis basats en certificats i normalment triga menys que la solució alternativa.
L'ordre importa. Inscriviu el substitut, connecteu-lo, envieu una petició de prova pel túnel i només després jubileu l'original. Conservar el telèfon que funciona fins que el nou estigui provat és l'assegurança més barata disponible, i només costa paciència.
Planifiqueu també els efectes secundaris d'un restabliment. Si es restableix la contrasenya del compte o es revoca la identitat del dispositiu, altres sessions poden quedar invalidades, inclòs un client d'ordinador portàtil i una tauleta que ningú no recordava. Ocupeu-vos-en a la mateixa finestra en lloc de descobrir-los un a un.
Què no s'ha de fer
No rootegeu l'únic dispositiu que funciona per buscar un fitxer de text pla. Convertiu un problema de recuperació d'accés en un problema d'integritat del dispositiu, podeu trencar les comprovacions d'integritat de la mateixa aplicació i encara no teniu cap garantia que el valor que busqueu existeixi en forma llegible.
No enganxeu claus privades, perfils exportats ni contrasenyes en un tiquet de suport per demostrar que el problema és real. El proveïdor necessita el nom del perfil, la versió de l'aplicació, l'identificador del compte i l'error, cap dels quals no és secret.
I no desactiveu la verificació de certificats per obtenir una connexió mentre espereu. Això canvia un inconvenient temporal per un debilitament permanent de l'única comprovació que us diu amb quin servidor parleu. Anoteu els quatre fets, feu la pregunta concreta i utilitzeu el camí emès.