Tethering reverso no Android por USB: comandos, verificações e reversão
O tethering reverso envia o tráfego do telefone por um relé no host. Construa o caminho do telefone ao host, mantenha a VPN do host no circuito e verifique cada salto.
O tethering reverso move o tráfego de um telefone para um computador e o faz sair pela conexão desse computador. Só um cabo USB não faz isso: o telefone precisa de um serviço de captura que assuma o encaminhamento, e o computador precisa de um relé que leve esses pacotes adiante. O caminho tem quatro saltos: aplicação, captura no telefone, relé USB e saída do host, e cada um tem um dono diferente. Este manual constrói esse caminho, coloca a VPN do host no lugar certo e verifica cada salto antes de você confiar no resultado.
Mapeie os saltos antes de executar qualquer coisa
Cada salto aplica a sua própria política, por isso um resultado que funciona numa ponta não diz nada sobre a outra. A aplicação escolhe um destino e um resolvedor, o serviço de captura decide qual tráfego entra no relé, o relé encaminha para os sockets do host, e o encaminhamento e a VPN do host decidem o endereço que o destino acaba vendo.
| Hop | Owner | What it decides |
|---|---|---|
| Application request | The app | Destination, resolver, address family |
| Capture service | Phone VpnService app | Which traffic enters the relay at all |
| ADB relay | Host process | Forwarding phone flows to host sockets |
| Host egress | Host routing and VPN | Exit address and host policy |
Só um cliente do serviço de VPN pode ocupar o papel de captura do telefone de cada vez, então um segundo aplicativo VPN comum não se empilha sobre o relé. Se a VPN pertence ao computador, o serviço de captura é o elo de acesso para esse computador, não a prova de que um túnel remoto já protege o resultado.
Prepare o relé antes de tocar no telefone
Gnirehtet é o exemplo documentado dessa arquitetura: um cliente do serviço de VPN sem root no telefone mais um relé transportado via ADB no host, com suporte a TCP e UDP sobre IPv4. O repositório também afirma que o projeto não é mais mantido ativamente, então trate-o como o desenho de referência e uma ferramenta funcional para um laboratório, não como um produto com suporte para padronizar numa frota gerenciada.
adb devices
adb shell getprop ro.build.version.release
gnirehtet run
Execute primeiro adb devices. Um telefone que não aceitou a chave de depuração do host é reportado como não autorizado, e o relé não se conecta até que o aviso no dispositivo seja aceito. gnirehtet run instala o cliente, inicia o relé e ativa a captura; numa versão que separa as etapas, use em vez disso os subcomandos documentados install, relay e start.
O acesso ADB é uma relação de controle do dispositivo, não uma configuração de rede. Autorize apenas um computador que você controla, e planeje revogar essa autorização quando a tarefa terminar.
Devolva a VPN do host ao caminho
O relé é um processo comum do host, então as suas conexões seguintes seguem a tabela de encaminhamento do host. Um perfil de túnel completo as transporta; um túnel dividido talvez não. Se a VPN do host usa controles por aplicativo, adicione o binário do relé ao conjunto permitido, caso contrário o relé continua usando a interface física enquanto o navegador parece protegido.
ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relay
Execute os dois primeiros comandos antes e depois de conectar a VPN do host. Se o endereço não mudar, o relé não está no túnel, diga o que disser a janela do cliente. Um túnel só para redes privadas também deixa os destinos públicos na saída normal do host, o que parece um vazamento mas é a política que você configurou.
O DNS é resolvido no host para o tráfego que passa pelo relé, então o resolvedor do host decide qual servidor vê os nomes. Uma configuração de DNS privado no telefone não atravessa o relé, e um teste de resolvedor do lado do telefone não descreverá as consultas do host.
Verifique cada salto separadamente
Três verificações, nesta ordem: o telefone alcança o relé, o relé alcança o destino sob a política do host, e a aplicação resolve e usa esse destino corretamente. Pare na primeira falha em vez de recarregar páginas e adivinhar.
adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:V
Uma entrada de rede VPN no dump de conectividade mostra que o serviço de captura está ativo; o próprio log do relé mostra se os fluxos chegam. A ausência num dos dois separa o problema com clareza: sem captura é o lado do telefone, sem fluxos é o lado do host.
Um navegador que funciona no host prova o caminho do navegador do host, não o do processo do relé. Compare os endereços que cada um relata, e teste um recurso privado e também uma página pública, porque um túnel só para redes privadas pode encaminhar um e não o outro.
Desmonte e escolha o comportamento em caso de falha
A reversão faz parte do manual. Pare e remova o relé, desinstale o cliente de captura e revogue a autorização de depuração do host nas opções de desenvolvedor do telefone quando a tarefa terminar.
gnirehtet stop
gnirehtet uninstall
adb kill-server
Decida o que o telefone deve fazer quando o relé desaparece. Sem uma escolha explícita ele pode voltar aos dados móveis e vazar o tráfego que você tentava encaminhar, então defina o comportamento de bloqueio de conexões ou a política de VPN de propósito e teste a desmontagem antes de confiar nela.
Registre o host que foi autorizado, a versão do relé, a política de túnel do host e os passos de desmontagem. Esse registro é o que torna a próxima configuração de tethering reverso repetível em vez de mais uma tarde de redescoberta.