Por qué el tráfico de depuración inalámbrica no demuestra una fuga de VPN

Activó la depuración inalámbrica, conectó un portátil y la sesión siguió funcionando mientras la VPN estaba activa. Parece que algo se coló por el túnel. Casi con total seguridad, no. Una sesión de depuración y la petición de una aplicación a un sitio web son relaciones de red distintas, y solo una de ellas debería cruzar el túnel.

Me he encontrado con esta lectura errónea dos veces: una con el teléfono y el portátil en la misma Wi-Fi, y otra tras un reinicio, cuando el emparejamiento sobrevivió. En ambos casos la VPN hacía exactamente aquello para lo que estaba configurada.

Nombre la observación antes de nombrar el fallo

Tres eventos pueden preceder a una afirmación de fuga, y no son intercambiables. Una herramienta puede descubrir un servicio, el dispositivo puede aprobar una estación de trabajo o una sesión autorizada puede transportar realmente comandos y bytes. Anote cuál vio, porque cada uno demuestra menos de lo que la gente supone.

El descubrimiento suele ser mDNS o un escaneo de puertos. El emparejamiento es una decisión de registro tomada en el teléfono, confirmada con un código que el usuario teclea. Una sesión activa significa que el tráfico se movió entre dos extremos emparejados. Nada de eso describe adónde va la petición HTTPS de una aplicación.

Mantenga el destino, la interfaz, la familia de direcciones, la marca temporal y el perfil de usuario vinculados al evento. Sin esos detalles, la observación no puede compararse con la política de red local prevista ni con la compilación de VPN que se ejecutaba entonces.

Por qué los dos caminos nunca se encuentran

La depuración inalámbrica es una conexión entrante al dispositivo. adbd escucha en un puerto vinculado a la interfaz Wi-Fi, y la estación de trabajo se conecta a él tras el emparejamiento. La dirección importa: su portátil llega hasta el teléfono, no al contrario. Eso es lo contrario de una fuga de salida.

El tráfico de internet de una aplicación sale por la interfaz de túnel que instala VpnService, emparejada por UID y reglas de enrutamiento. adbd es un demonio del sistema que se ejecuta como usuario shell, no una aplicación dentro de ese conjunto de enrutamiento. Permanece en el enlace Wi-Fi subyacente incluso cuando cada aplicación está fijada al túnel.

El modo de bloqueo impone el túnel a las aplicaciones cubiertas. No convierte un socket a la escucha en una ruta de salida.

Por eso una sesión ADB funcional y un interruptor de seguridad funcional coexisten sin contradicción. Para demostrar una fuga hay que observar la dirección que debería estar bloqueada.

Cómo es realmente una prueba de salida

Pruebe la aplicación cubierta, no el canal de depuración. Prepare la condición de fallo deliberadamente, luego haga una petición nueva y registre qué ocurrió.

1. Confirme que la VPN es el único camino: active la VPN siempre activa con el bloqueo de conexiones sin VPN.
2. Detenga la VPN de la forma admitida y confirme que la aplicación informa de que no hay conectividad.
3. Envíe una petición inofensiva desde esa aplicación y anote si falla o tiene éxito.
4. Repita con la depuración inalámbrica activada y luego desactivada, para aislar la variable.

Una petición bloqueada en esas condiciones es una prueba. Una sesión ADB exitosa no lo es, y un solo ping desde una aplicación de terminal tampoco.

Si la petición sí tiene éxito mientras el bloqueo está activo, capture el UID de la aplicación y su permiso de VPN, la red activa y la versión del cliente. Esa combinación es un hallazgo real.

El emparejamiento sobrevive a la sesión

El emparejamiento es un estado persistente, no un apretón de manos que pueda olvidar tras la prueba con cable. La documentación de depuración de Android describe el flujo de trabajo inalámbrico y señala que la relación dura hasta que se olvida explícitamente o se revocan las autorizaciones.

Compruebe qué sigue autorizado antes de culpar al túnel. Abra Depuración inalámbrica, mire Dispositivos emparejados y olvide todo lo que ya no reconozca. Ejecute adb devices desde la estación de trabajo para ver qué entradas siguen respondiendo, y adb disconnect para descartar una obsoleta. Desactivar la depuración inalámbrica cierra por completo el puerto de escucha.

En una red compartida o no confiable, déjela desactivada. Una autorización persistente en una red que no controla es un problema mayor que una hipotética elusión del TUN.

Antes de presentar ese fallo

Un informe útil nombra el límite exacto que falló. Incluya el modelo del dispositivo y la versión de Android, el cliente VPN y su versión, si el bloqueo estaba activado, el paquete de la aplicación y el UID, y la red en la que estaba el teléfono. Añada el comando o la petición que produjo la observación, además de la hora en que ocurrió. Sin eso, nadie puede reproducir el límite que afirma que está roto.

No desactive la aplicación forzosa ni exponga la depuración en una red no confiable para que la prueba parezca más dramática. Eso cambia el sistema que está midiendo y deja pruebas que nadie puede repetir.

Si su única prueba es que ADB se conectó mientras la VPN estaba activa, midió el camino equivocado. Vuelva a ejecutar primero la prueba a nivel de aplicación; la respuesta suele llegar ahí.