O modo SOCKS do NetGuard cobre TCP, não todos os protocolos

O NetGuard ocupa a interface VPN do Android para filtrar o tráfego, e pode entregar as conexões suportadas a um endpoint SOCKS. Estes dois factos são frequentemente lidos como «o telefone está numa VPN», uma conclusão que o mecanismo não sustenta. O filtro vê pacotes; o proxy só vê as conexões que lhe foram efetivamente entregues. Entre estas duas afirmações está toda a questão da cobertura.

As FAQ do projeto original documentam tanto a limitação a um único serviço como a opção SOCKS. A existência da opção não é prova de que cada pacote permitido a use, e é desta lacuna que surgem as questões de cobertura.

Dois caminhos de encaminhamento numa só aplicação

O lado TCP da implementação contém o tratamento de ligações SOCKS, pelo que uma ligação TCP permitida pode ser negociada com o proxy e transportada através dele. O lado UDP tem um caminho de socket separado, e o seu tratamento de envio e receção não depende dessa negociação TCP. Por isso, um datagrama que o filtro permite pode chegar à rede comum sem nunca passar pelo proxy. Nada disto é um defeito da aplicação; é simplesmente o que os dois caminhos implementam.

Esta distinção tem uma consequência que as pessoas descrevem mal em ambas as direções. Chamar fuga a cada pacote UDP ignora as regras de bloqueio, porque um datagrama negado nunca sai. Chamar VPN a todo o arranjo ignora o caminho direto permitido, porque parte do tráfego sai de facto sem proxy. O que tem é um dispositivo filtrado com proxy parcial, e a descrição honesta é uma matriz, não um rótulo.

Anunciar UDP não é implementá-lo

Um servidor SOCKS que afirma suportar UDP não acrescenta o tratamento correspondente do lado do cliente à aplicação no seu telefone. As características teóricas do protocolo e o comportamento da compilação instalada são temas diferentes, e só o segundo descreve o seu tráfego.

Verifique a versão e a configuração que realmente executa, depois teste um fluxo de datagramas inofensivo e observe se aparece no proxy. Qualquer outra coisa é uma inferência a partir de uma lista de funcionalidades, e as listas de funcionalidades descrevem intenções, não caminhos de código.

DNS é um terceiro caminho, não um detalhe

A resolução de nomes acrescenta o seu próprio ramo à matriz. Um reencaminhador DNS local, uma consulta UDP comum, um nome de anfitrião de destino resolvido pelo próprio proxy e um resolvedor cifrado no navegador são quatro arranjos distintos. Diferem em quem vê a consulta e em que caminho de rede a transporta, e misturá-los produz um teste que nada prova sobre os outros.

Decida deliberadamente qual quer. Se o requisito é que os nomes sejam resolvidos através do túnel, uma simples definição do navegador não o garante, e um proxy que resolve ele mesmo os nomes de anfitrião só altera a resposta para as ligações que realmente trata.

O transporte pelo proxy não é privado automaticamente

SOCKS simples não é uma ligação cifrada entre o telefone e o proxy. Se o endpoint for alcançado por outro caminho protegido, nomeie esse caminho e a sua política de falha, porque uma queda para a rede aberta torna um arranjo privado em público sem aviso. A autenticação do próprio proxy também conta: um ouvinte aberto num dispositivo partilhado é um serviço de que ninguém presta contas.

Os arranjos entre perfis merecem o mesmo escrutínio. Uma VPN de perfil de trabalho só protege o tráfego que usa o seu caminho, e a coexistência de uma firewall de perfil pessoal com um túnel de trabalho não prova que a ligação posterior da firewall chegue a esse túnel. Verifique a acessibilidade e a autenticação em vez de presumir que os dois perfis cooperam.

Audite a cobertura com uma matriz, não com um carregamento de página

Para uma avaliação autorizada, escolha exemplos inofensivos que representem cada classe que lhe importa: TCP necessário, UDP permitido e DNS em ambas as famílias de endereços. Para cada um, registe se passou pelo proxy, se foi bloqueado ou enviado diretamente. Essa única tabela é o resultado, e é muito mais útil do que uma captura de ecrã de uma página carregada.

Se o requisito é que todo o tráfego de aplicações selecionado atravesse um túnel remoto, escolha uma implementação com filtragem e tunelização combinadas explicitamente suportadas. Uma composição de proxy apenas TCP continua útil para tarefas mais estreitas, desde que o outro tráfego seja tratado de propósito e não esquecido.