Por que o tráfico de depuración sen fíos non demostra unha fuga de VPN

Activou a depuración sen fíos, conectou un portátil e a sesión seguiu funcionando mentres a VPN estaba activa. Parece que algo se colou polo túnel. Case con toda seguridade, non. Unha sesión de depuración e a petición dunha aplicación a un sitio web son relacións de rede distintas, e só unha delas debería cruzar o túnel.

Atopei esta lectura errónea dúas veces: unha co teléfono e o portátil na mesma Wi-Fi, e outra tras un reinicio, cando o emparellamento sobreviviu. En ambos os casos a VPN facía exactamente aquilo para o que estaba configurada.

Nomee a observación antes de nomear o fallo

Tres eventos poden preceder unha afirmación de fuga, e non son intercambiables. Unha ferramenta pode descubrir un servizo, o dispositivo pode aprobar unha estación de traballo ou unha sesión autorizada pode transportar realmente comandos e bytes. Anote cal viu, porque cada un demostra menos do que a xente supón.

O descubrimento adoita ser mDNS ou unha exploración de portos. O emparellamento é unha decisión de rexistro tomada no teléfono, confirmada cun código que o usuario teclea. Unha sesión activa significa que o tráfico se moveu entre dous extremos emparellados. Nada diso describe a onde vai a petición HTTPS dunha aplicación.

Manteña o destino, a interface, a familia de enderezos, a marca temporal e o perfil de usuario vinculados ao evento. Sen eses detalles, a observación non se pode comparar coa política de rede local prevista nin coa compilación de VPN que se executaba daquela.

Por que os dous camiños nunca se atopan

A depuración sen fíos é unha conexión entrante ao dispositivo. adbd escoita nun porto vinculado á interface Wi-Fi, e a estación de traballo conéctase a el tras o emparellamento. A dirección importa: o seu portátil chega ata o teléfono, non ao revés. Iso é o contrario dunha fuga de saída.

O tráfico de internet dunha aplicación sae pola interface de túnel que instala VpnService, emparellada por UID e regras de enrutamento. adbd é un demonio do sistema que se executa como usuario shell, non unha aplicación dentro dese conxunto de enrutamento. Permanece na ligazón Wi-Fi subxacente mesmo cando cada aplicación está fixada ao túnel.

O modo de bloqueo impón o túnel ás aplicacións cubertas. Non converte un socket á escoita nunha ruta de saída.

Por iso unha sesión ADB funcional e un interruptor de seguridade funcional coexisten sen contradición. Para demostrar unha fuga, hai que observar a dirección que debería estar bloqueada.

Como é realmente unha proba de saída

Probe a aplicación cuberta, non a canle de depuración. Prepare a condición de fallo deliberadamente, logo faga unha petición nova e rexistre que ocorreu.

1. Confirme que a VPN é o único camiño: active a VPN sempre activa co bloqueo de conexións sen VPN.
2. Detéña a VPN do xeito admitido e confirme que a aplicación informa de que non hai conectividade.
3. Envíe unha petición inofensiva desde esa aplicación e anote se falla ou ten éxito.
4. Repita coa depuración sen fíos activada e logo desactivada, para illar a variable.

Unha petición bloqueada nesas condicións é unha proba. Unha sesión ADB exitosa non o é, e un só ping desde unha aplicación de terminal tampouco.

Se a petición si ten éxito mentres o bloqueo está activo, capture o UID da aplicación e o seu permiso de VPN, a rede activa e a versión do cliente. Esa combinación é un achado real.

O emparellamento sobrevive á sesión

O emparellamento é un estado persistente, non un aperta de mans que poida esquecer tras a proba con cable. A documentación de depuración de Android describe o fluxo de traballo sen fíos e sinala que a relación dura ata que se esquece explicitamente ou se revogan as autorizacións.

Comprobe que segue autorizado antes de culpar o túnel. Abra Depuración sen fíos, mire Dispositivos emparellados e esqueza todo o que xa non recoñeza. Execute adb devices desde a estación de traballo para ver que entradas seguen respondendo, e adb disconnect para descartar unha obsoleta. Desactivar a depuración sen fíos pecha por completo o porto de escoita.

Nunha rede compartida ou non fiable, déixea desactivada. Unha autorización persistente nunha rede que non controla é un problema maior que unha hipotética elusión do TUN.

Antes de presentar ese fallo

Un informe útil nomea o límite exacto que fallou. Inclúa o modelo do dispositivo e a versión de Android, o cliente VPN e a súa versión, se o bloqueo estaba activado, o paquete da aplicación e o UID, e a rede na que estaba o teléfono. Engada o comando ou a petición que produciu a observación, ademais da hora en que ocorreu. Sen iso, ninguén pode reproducir o límite que afirma que está roto.

Non desactive a aplicación forzosa nin expoña a depuración nunha rede non fiable para que a proba pareza máis dramática. Iso cambia o sistema que está a medir e deixa probas que ninguén pode repetir.

Se a súa única proba é que ADB se conectou mentres a VPN estaba activa, mediu o camiño equivocado. Volva executar primeiro a proba a nivel de aplicación; a resposta adoita chegar aí.