VPN guardada en Android: ¿qué secreto puedes recuperar?
Un teléfono que se vuelve a conectar sin pedir contraseña no guarda ninguna que puedas copiar. Compara las cuatro credenciales y la recuperación que necesita cada una.
El teléfono se vuelve a conectar a la VPN cada mañana sin pedir nada. Eso implica que la credencial está ahí dentro en algún sitio. Normalmente no lo está, al menos no en una forma que puedas leer en voz alta y escribir en un dispositivo nuevo.
Lo que tiene el teléfono es autoridad para conectarse. Lo que tú quieres es un secreto que puedas llevar contigo, y son propiedades distintas que casualmente producen el mismo comportamiento en pantalla.
Antes de restablecer nada, identifica cuál de los cuatro tipos de secreto falta realmente, porque cada uno tiene un propietario distinto y una recuperación distinta.
Una conexión que funciona no es una contraseña guardada
Una aplicación que se reconecta en silencio puede estar guardando una contraseña, un token de sesión, una referencia a un certificado o nada más que una clave vinculada al dispositivo que no puede exportar. Las cuatro producen la misma experiencia de usuario y ninguna es intercambiable.
Una fila de puntos en un campo de ajustes es una decisión de representación, no una prueba. Algunas aplicaciones guardan de verdad una contraseña recuperable y ofrecen revelarla o exportarla; otras toman un token de un flujo de inicio de sesión único y nunca ven la contraseña.
Así que la primera pregunta no es dónde está el archivo. Es qué tipo de autoridad recibió la aplicación, y esa respuesta viene del proveedor, no del dispositivo.
Cuatro secretos, cuatro recuperaciones
Encaja tu situación en una fila antes de contactar con nadie, porque la petición cambia por completo según cuál sea.
| 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 segunda fila es la que más atrapa a la gente. Una contraseña de importación PKCS#12 protege material de clave y no tiene relación con el inicio de sesión de la cuenta, así que restablecer la contraseña de la cuenta no recupera nada. Si la contraseña del paquete se ha perdido de verdad, la solución es reemitirlo.
La cuarta fila explica muchos hilos de soporte confusos. El perfil puede referenciar una credencial en el almacén de claves de la plataforma en lugar de contener una copia portátil, y en ese caso no hay nada en el perfil que extraer ni siquiera en principio.
Por qué copiar los datos de la aplicación suele fallar
La receta antigua es extraer el directorio de datos de la aplicación y leer la configuración de ahí. En el Android actual la receta tiene dos problemas independientes.
El primero es la política de copias de seguridad. Android 12 restringió los datos de aplicaciones exportados por la ruta antigua adb backup para aplicaciones dirigidas a API 31 o posterior, y las aplicaciones pueden excluir los datos de la copia de seguridad por completo. Un procedimiento escrito para un dispositivo antiguo no es un método de recuperación universal para uno actual.
El segundo es el almacén de claves. Las claves generadas allí pueden ser no exportables y estar vinculadas al hardware, como describe la documentación de Android Keystore. Copiar un blob cifrado no copia la clave que lo descifra, así que un directorio restaurado puede contener una credencial que el dispositivo nuevo nunca podrá usar.
Ninguno de los dos problemas es un fallo que haya que sortear. Ambos son la plataforma haciendo lo que fue diseñada para hacer, y tratarlos como obstáculos suele acabar con un teléfono rooteado y sin contraseña.
Pasa a un teléfono de sustitución de forma deliberada
Haz primero lo que está soportado. Si el proveedor ofrece una exportación que incluya explícitamente las credenciales que necesitas, úsala y verifica el resultado en el dispositivo nuevo antes de borrar el antiguo. Si no la ofrece, pide un perfil o un registro nuevos, que es la vía normal para los servicios basados en certificados y suele llevar menos tiempo que el rodeo.
El orden importa. Registra el sustituto, conéctalo, envía una petición de prueba por el túnel y solo entonces retira el original. Conservar el teléfono que funciona hasta que el nuevo esté probado es el seguro más barato disponible, y solo cuesta paciencia.
Planifica también los efectos secundarios de un restablecimiento. Si se restablece la contraseña de la cuenta o se revoca la identidad del dispositivo, otras sesiones pueden quedar invalidadas, incluido un cliente de portátil y una tableta que nadie recordaba. Ocúpate de ellas en la misma ventana en lugar de descubrirlas una a una.
Qué no hacer
No rootees el único dispositivo que funciona para buscar un archivo de texto plano. Conviertes un problema de recuperación de acceso en un problema de integridad del dispositivo, puedes romper las comprobaciones de integridad de la propia aplicación y sigues sin tener garantía de que el valor que buscas exista en forma legible.
No pegues claves privadas, perfiles exportados ni contraseñas en un ticket de soporte para demostrar que el problema es real. El proveedor necesita el nombre del perfil, la versión de la aplicación, el identificador de la cuenta y el error, ninguno de los cuales es secreto.
Y no desactives la verificación de certificados para conseguir una conexión mientras esperas. Eso cambia una molestia temporal por un debilitamiento permanente de la única comprobación que te dice con qué servidor hablas. Anota los cuatro hechos, haz la pregunta concreta y usa la vía emitida.