Proxy SOCKS via SSH no Android: por que só metade dos seus apps se conecta

Você entra por SSH, adiciona -D 1080 e o comando funciona. Agora existe um ouvinte SOCKS no celular, e metade dos apps ainda sai pelos dados móveis. Esse é o resultado normal, não um túnel quebrado: ssh -D cria um ponto de extremidade de proxy, e os apps Android só usam proxy se algo os obrigar. Percorrer a cadeia passo a passo mostra onde cada parte do trabalho realmente vive.

Comece onde o tráfego começa

Escolha um app que deveria usar o túnel e verifique se ele tem configuração de proxy própria. Um navegador com campo SOCKS é o caso fácil: aponte-o para 127.0.0.1:1080, ative o DNS remoto se a configuração existir, e a requisição passa. Um cliente de chat, um app de mapas ou um jogo sem esse campo não têm como usar o ouvinte, e nada do que você digitar no comando SSH muda isso.

Antes de envolver qualquer outra coisa, prove que o ouvinte funciona do próprio shell do celular com um cliente que fale SOCKS diretamente:

ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

O endereço que volta deve ser o do servidor SSH, não o do celular. Se for, a metade proxy está pronta e o resto do trabalho é sobre cobertura. Se não for, conserte primeiro o lado SSH: autenticação por chave, a capacidade do servidor de alcançar o destino e a saída própria do servidor SSH.

Adicione a peça que o Android precisa

Apps sem configuração de proxy precisam de algo que capture seus pacotes e os transforme em conexões proxy. Num dispositivo sem root, isso é um adaptador de serviço VPN: um app que assume a interface virtual e encaminha o tráfego selecionado para o ouvinte SOCKS local. A cadeia vira app, adaptador, ouvinte SOCKS, conexão SSH, destino.

Instale o adaptador, conceda a permissão de VPN e escolha os apps ou rotas que ele deve capturar. O ícone de chave na barra de status passa a representar o adaptador, não uma VPN comercial separada. O Android permite uma única conexão de serviço VPN ativa por perfil de usuário, então iniciar um segundo app de VPN não acrescenta uma camada à cadeia: ele disputa o mesmo papel.

Também é o passo em que um teste bem-sucedido pode enganar você. Se o adaptador estiver configurado para capturar só o navegador que você já apontou para o proxy, tudo funciona e nada mais está coberto. Leia a lista de captura antes de concluir que o dispositivo está em túnel.

Mantenha o transporte SSH fora da captura

A própria conexão SSH não deve ser realimentada no túnel SOCKS que ela mantém. Se o adaptador captura o tráfego do app SSH, o túnel depende de uma conexão que espera o túnel, e o resultado é um laço que trava ou falha assim que o adaptador inicia.

Implementações integradas protegem o próprio socket de transporte. Com apps separados você precisa de uma exclusão suportada: deixe o app SSH fora da captura, ou exclua o endpoint SSH por endereço. Ambas têm custo. Excluir um app de terminal inteiro também retira do túnel a atividade de rede não relacionada dele, e uma exceção de endereço quebra quando o endereço do servidor muda ou quando o nome resolve diferente na conexão seguinte.

Verifique a exclusão de fora: reconecte o adaptador, depois confirme que a sessão SSH sobrevive e que a requisição via proxy ainda informa o endereço do servidor. Uma sessão que funciona até o adaptador iniciar e então congela é o laço.

Siga DNS e UDP até o fim da cadeia

O encaminhamento dinâmico do OpenSSH carrega conexões TCP. Não é um transporte UDP-associate nem ICMP, e um adaptador não pode inventar encaminhamento UDP aceitando pacotes UDP. Tudo que exige UDP, incluindo QUIC e mídia WebRTC, vai falhar ou cair para TCP conforme o app.

DNS precisa da própria decisão. Um app que resolve um nome localmente envia a consulta pelo resolvedor normal antes de conectar, então o túnel carrega a conexão mas não a busca. Um cliente consciente do proxy com opção de DNS remoto evita isso; um app capturado sem essa opção não. Verifique qual resolvedor respondeu em vez de supor que o adaptador mudou isso.

Mantenha o ouvinte SOCKS ligado ao loopback, verifique a chave de host do servidor SSH no primeiro uso e deixe a validação HTTPS normal no lugar para o site final. SSH protege o trecho celular-servidor; não criptografa o que o servidor faz depois.

Verifique as duas vidas e decida

O adaptador e a sessão SSH têm vidas separadas. Se o SSH cair enquanto o adaptador continua capturando, os apps podem travar sem erro evidente, porque os pacotes deles ainda entram numa interface virtual que não tem mais saída funcional. Se o adaptador parar, os apps ou vão direto ou são bloqueados, conforme a política de VPN do dispositivo.

Teste as duas direções de propósito: mate a sessão SSH com o adaptador rodando, depois pare o adaptador enquanto o SSH continua de pé. O que o celular faz em cada caso é a política que você realmente está implantando, diga o que disserem as instruções de instalação.

Se o fluxo de trabalho precisa de cobertura do dispositivo inteiro com um modo de falha previsível, uma VPN IP de verdade, ou um adaptador mantido e projetado para esta cadeia, é a resposta honesta. Uma sessão de shell deixada rodando ao lado de um app de captura não relacionado não é um túnel de dispositivo mantido; são dois componentes sem acordo sobre o que acontece quando um deles termina.