Porque o tráfego de depuração sem fios não prova uma fuga de VPN

Ativou a depuração sem fios, ligou um portátil e a sessão continuou a funcionar enquanto a VPN estava ativa. Parece que algo escapou pelo túnel. Quase de certeza que não. Uma sessão de depuração e o pedido de uma aplicação a um site são relações de rede diferentes, e só uma delas deve atravessar o túnel.

Já encontrei esta leitura errada duas vezes: uma com o telemóvel e o portátil na mesma Wi-Fi, e outra após um reinício, quando o emparelhamento sobreviveu. Em ambos os casos a VPN estava a fazer exatamente aquilo para que fora configurada.

Nomeie a observação antes de nomear o erro

Três eventos podem preceder uma alegação de fuga, e não são intermutáveis. Uma ferramenta pode descobrir um serviço, o dispositivo pode aprovar uma estação de trabalho ou uma sessão autorizada pode realmente transportar comandos e bytes. Anote qual viu, porque cada um prova menos do que as pessoas supõem.

A descoberta é normalmente mDNS ou uma análise de portas. O emparelhamento é uma decisão de registo tomada no telemóvel, confirmada com um código que o utilizador escreve. Uma sessão ativa significa que o tráfego passou entre dois pontos finais emparelhados. Nada disso descreve para onde vai o pedido HTTPS de uma aplicação.

Mantenha o destino, a interface, a família de endereços, o carimbo temporal e o perfil de utilizador associados ao evento. Sem esses detalhes, a observação não pode ser comparada com a política de rede local prevista, nem com a versão da VPN que estava a correr na altura.

Porque os dois caminhos nunca se encontram

A depuração sem fios é uma ligação de entrada ao dispositivo. O adbd escuta numa porta ligada à interface Wi-Fi, e a estação de trabalho liga-se a ela após o emparelhamento. A direção importa: o seu portátil chega ao telemóvel, não o contrário. É o oposto de uma fuga de saída.

O tráfego de internet de uma aplicação sai pela interface de túnel que o VpnService instala, emparelhado por UID e regras de encaminhamento. O adbd é um daemon de sistema executado como utilizador shell, não uma aplicação dentro desse conjunto de encaminhamento. Permanece na ligação Wi-Fi subjacente mesmo quando cada aplicação está fixada ao túnel.

O modo de bloqueio impõe o túnel às aplicações abrangidas. Não transforma um socket à escuta num percurso de saída.

É por isso que uma sessão ADB funcional e um interruptor de segurança funcional coexistem sem contradição. Para provar uma fuga, tem de observar a direção que deveria estar bloqueada.

Como é realmente um teste de saída

Teste a aplicação abrangida, não o canal de depuração. Crie deliberadamente a condição de falha, faça depois um novo pedido e registe o que aconteceu.

1. Confirme que a VPN é o único caminho: ative a VPN sempre ativa com o bloqueio de ligações sem VPN.
2. Pare a VPN da forma suportada e confirme que a aplicação indica ausência de conetividade.
3. Envie um pedido inofensivo a partir dessa aplicação e anote se falha ou tem sucesso.
4. Repita com a depuração sem fios ativa e depois desativada, para isolar a variável.

Um pedido bloqueado nessas condições é prova. Uma sessão ADB bem-sucedida não é, tal como um único ping de uma aplicação de terminal.

Se o pedido tiver sucesso com o bloqueio ativo, registe o UID da aplicação e a sua autorização de VPN, a rede ativa e a versão do cliente. Essa combinação é um achado real.

O emparelhamento sobrevive à sessão

O emparelhamento é um estado persistente, não um aperto de mão que se esquece após o teste do cabo. A documentação de depuração do Android descreve o fluxo de trabalho sem fios e nota que a relação dura até ser explicitamente esquecida ou as autorizações serem revogadas.

Verifique o que ainda está autorizado antes de culpar o túnel. Abra Depuração sem fios, veja Dispositivos emparelhados e esqueça tudo o que já não reconhece. Execute adb devices a partir da estação de trabalho para ver que entradas ainda respondem, e adb disconnect para remover uma obsoleta. Desativar a depuração sem fios fecha completamente a porta à escuta.

Numa rede partilhada ou não fidedigna, deixe-a desativada. Uma autorização persistente numa rede que não controla é um problema maior do que uma hipotética evasão ao TUN.

Antes de comunicar esse erro

Um relatório útil nomeia o limite exato que falhou. Inclua o modelo do dispositivo e a versão do Android, o cliente VPN e a versão, se o bloqueio estava ativo, o pacote da aplicação e o UID, e a rede em que o telemóvel estava. Acrescente o comando ou pedido que produziu a observação, bem como a hora a que ocorreu. Sem isso, ninguém consegue reproduzir o limite que afirma estar quebrado.

Não desative a aplicação das regras nem exponha a depuração numa rede não fidedigna para tornar o teste mais dramático. Isso altera o sistema que está a medir e deixa provas que ninguém consegue repetir.

Se a sua única prova é que o ADB se ligou enquanto a VPN estava ativa, mediu o caminho errado. Execute primeiro o teste ao nível da aplicação; a resposta costuma chegar aí.