Cómo recopilar registros de VPN de Android para un ticket de soporte

Pulsa Conectar, el perfil gira un segundo y el cliente informa de desconexión. Soporte pide registros, adjuntas una captura de pantalla y el hilo se detiene dos días porque nadie puede decir qué parte del saludo inicial se rindió. Un informe construido en torno a un solo intento, con una ventana de tiempo estrecha y la última etapa completada, mueve el ticket en una sola ronda. La alternativa, un día completo de registros del teléfono, normalmente da a la persona del otro lado más lugares donde mirar.

Dos teléfonos en la misma puerta de enlace pueden comportarse distinto, porque el protocolo, el almacén de certificados, el método de autenticación o la política de tráfico pueden no coincidir. Funciona en mi iPhone es un punto de partida para comparar, no una prueba sobre un fallo de Android.

Capture un intento en lugar de un día de historial

Anote el entorno antes de reproducir nada: versión de Android, fabricante y modelo, nombre y versión del cliente, el perfil seleccionado, la red a la que está conectado y la hora del reloj con su zona horaria. También anoto si están activados el ahorro de batería o Data Saver, porque ambos cambian lo que el cliente puede hacer cuando se apaga la pantalla.

Después decida cuál de los cinco resultados está viendo realmente. El aviso de consentimiento o permiso nunca se completa, no se puede alcanzar el extremo, se rechaza la autenticación, falla la configuración de la interfaz tras un inicio de sesión correcto, o el túnel se levanta y un recurso concreto sigue inaccesible. Cada uno tiene un responsable distinto y una solución distinta, y un paquete que los mezcla recibe una respuesta pidiendo que lo intente de nuevo. Adivinar entre ellos es lo que convierte un ticket de una hora en una semana de idas y venidas.

Las transiciones también importan. Si el fallo solo aparece tras bloquear la pantalla o tras pasar de Wi-Fi a datos móviles, póngalo en la primera línea del ticket y anote el minuto en que ocurrió.

Exporte primero el registro propio del cliente

El primer adjunto debería venir de la aplicación y no del sistema operativo. La mayoría de los clientes incluyen en los ajustes una exportación de registro de diagnóstico o de conexión, a veces escondida tras una pulsación larga en la cadena de versión, y esa exportación ya entiende su propia máquina de estados. Úsela tal como sale en lugar de reescribir las líneas interesantes en el cuerpo del ticket.

Adjunte el primer error y los eventos inmediatamente anteriores, no solo la última línea de desconexión. Una cola limpia suele significar que el fallo real ocurrió antes: una cadena de certificados que no validaba, un nombre que se resolvió en un lugar inesperado o una interfaz que nunca se configuró.

Añada logcat solo para una pregunta que pueda nombrar

Un emulador de terminal en el teléfono no es un registrador del sistema. Android registra sus búferes como flujos circulares separados que solo los procesos privilegiados pueden leer por completo. Así, una aplicación normal ve su propia salida más una porción restringida, y afirmar que logcat estaba vacío demuestra muy poco sobre lo que registró la plataforma.

La vía admitida es una sesión ADB autorizada desde un ordenador que controle. Active las opciones de desarrollador y la depuración USB, conecte el cable y acepte el diálogo de huella RSA en el dispositivo; si ese aviso se descarta, cada comando posterior falla con unauthorized y no empieza ninguna captura.

Confirme que el dispositivo está realmente ahí antes de invertir tiempo en una captura. adb devices debería imprimir el número de serie seguido de la palabra device, y cualquier cosa que muestre offline o unauthorized necesita primero arreglar el cable, el aviso o el controlador.

Una vez que aparezca en la lista, empiece a capturar unos segundos antes de pulsar Conectar y deténgase justo después de que el cliente se rinda. Una captura en vivo con un inicio deliberado supera a un volcado tomado veinte minutos después, porque los búferes circulares ya han girado y las líneas iniciales que necesita pueden haber desaparecido:

adb logcat -v threadtime -b main,system,crash > attempt.txt

Filtre por hora y etiqueta en lugar de por la palabra VPN

Buscar vpn en una captura es la forma más rápida de perder la línea que explica el fallo. La validación de certificados, los fallos de proceso y los cambios de conectividad se registran bajo etiquetas que nunca mencionan VPN, así que un filtro por palabra clave conserva el ruido y tira la evidencia.

Estreche primero la ventana, luego la prioridad y luego la etiqueta. Cuando solo necesita lo que ocurrió después de un momento conocido, adb logcat -v threadtime -t '11-03 20:14:00.000' reproduce la cola reciente desde ese punto, y el formato threadtime mantiene las marcas de tiempo comparables con la exportación propia del cliente.

Si conoce el paquete del cliente, siga su proceso en lugar de adivinar etiquetas. adb shell pidof com.vendor.client devuelve un PID y adb logcat --pid=1234 -v threadtime imprime solo ese proceso, mientras que adb logcat -g muestra cuánto espacio tiene cada búfer antes de empezar a sobrescribir.

Oculte los secretos y entregue un paquete coherente

Antes de que algo salga de su máquina, elimine contraseñas, tokens, claves privadas, cookies de sesión e identificadores completos del dispositivo. Conserve los códigos de error, el orden de los eventos y las relaciones de direcciones que hacen legible el fallo, porque una captura limpiada más allá de ese punto es tan inútil como una que nunca se filtró.

Después envíe un solo paquete en lugar de varios archivos sueltos: la exportación del cliente, la ventana ADB nombrada con su hora de inicio y fin, un resumen de dos líneas de la etapa que falló y la nota de entorno de la parte superior de esta lista. Si parte no puede publicarse en público, use el canal de soporte privado del proveedor y diga qué archivo necesita ese canal.

Antes de enviar, compruebe cuatro cosas. ¿Cubre el paquete un intento y no toda una tarde? ¿Se solapan las marcas de tiempo del cliente y del sistema? ¿Y sigue conteniendo un token, una contraseña o un identificador completo de suscriptor? Corrija primero ese último punto y luego adjunte los archivos al ticket existente en lugar de abrir uno nuevo, para que quien lo recoja conserve el contexto anterior.