Redirecionamento de portas no hotspot do Android: três pontos de entrada

Você ligou o hotspot, conectou a VPN, abriu uma porta no aplicativo, e o outro dispositivo ainda não consegue se conectar. A peça que falta quase nunca é a própria porta. Trata-se de saber qual máquina é dona do socket de escuta e qual endereço outro dispositivo deve alcançar. Examino isso do telefone para fora, porque a tela em que você está indica qual dos três pontos de entrada você está realmente testando.

Comece onde o serviço realmente roda

Abra o aplicativo que deveria aceitar a conexão e leia a própria página de status. Se ele disser que está escutando, anote o endereço ao qual se vinculou, porque esse único detalhe decide a maioria dos casos abaixo. Um aplicativo vinculado a 127.0.0.1 só é alcançável pelo próprio telefone, e nenhum cliente de hotspot, mapeamento da operadora ou saída de VPN mudará isso.

Depois confirme qual dispositivo executa o serviço. É o telefone, e nesse caso o socket pertence ao aplicativo, ou um laptop atrás do hotspot, e nesse caso o listener e o firewall pertencem ao laptop e o telefone apenas encaminha pacotes. São projetos diferentes com donos diferentes, e misturá-los é o motivo pelo qual uma porta aberta em um lugar não faz nada no outro.

Em uma compilação depurável, o adb shell consegue listar sockets por /proc/net/tcp, mas para a maioria das pessoas o status do próprio aplicativo é a fonte honesta. Isso também evita a armadilha de testar um socket que o aplicativo abriu em um endereço que você não esperava.

Primeiro ponto de entrada: outro dispositivo no hotspot

Este é o caso local e o mais fácil de acertar. O outro dispositivo alcança o telefone no endereço que vê como seu gateway, na porta em que o aplicativo escuta, e nada fora do hotspot precisa estar envolvido. Nenhum mapeamento da operadora é necessário e nenhum recurso do provedor precisa existir, porque o tráfego nunca sai do segmento local.

Duas coisas quebram isso. O aplicativo vinculado ao loopback, ou a política de cliente no telefone não permite a conexão local. Teste com o protocolo do próprio aplicativo em vez de uma conexão TCP crua se o aplicativo autentica, porque um listener que aceita e depois rejeita parece idêntico a uma porta fechada à distância.

Se o serviço roda em um laptop conectado ao telefone, o endereço do hotspot do telefone não é o destino de forma alguma. Você precisa do endereço do laptop na interface do hotspot e de um listener no laptop, e o telefone deixa de ser dono de qualquer coisa além do encaminhamento.

Segundo ponto de entrada: o caminho da operadora

Alcançar o telefone a partir da rede móvel é outro problema, e na maioria das vezes simplesmente não funciona para IPv4. As operadoras colocam aparelhos atrás de tradução compartilhada, e por isso a RFC 6598 reservou uma faixa de endereços compartilhados exatamente para esse arranjo. Uma conexão de entrada não solicitada não tem mapeamento por onde chegar, e nenhuma configuração local cria um, porque o tradutor não é o seu dispositivo.

O acesso root também não muda isso. Ele dá controle sobre a pilha do telefone, não sobre o tradutor da operadora, e receitas que prometem o contrário geralmente presumem um endereço público que a operadora nunca atribuiu. Onde a operadora oferece um prefixo IPv6 público, um caminho de entrada pode existir, mas o listener e o firewall do telefone ainda precisam de autorização deliberada antes que algo responda.

Terceiro ponto de entrada: a saída da VPN

O endereço que um site informa enquanto o túnel está ativo é o endereço da saída para o tráfego de saída coberto. Isso não é o mesmo que um endereço que aceita conexões de entrada em seu nome. Usá-lo para entrada exige um recurso que o provedor realmente ofereça, como uma porta encaminhada ou um mapeamento de entrada vinculado à sua conta, além de um caminho utilizável da saída até o cliente.

Uma regra de permissão local não pode fabricar esse mapeamento. O que ela pode fazer é mudar por qual caminho as respostas do aplicativo saem, o que importa quando o aplicativo está excluído do túnel: a solicitação e a resposta podem acabar em contextos de rede diferentes, e a conexão falha de um modo que parece um problema de firewall.

Teste um caminho de ponta a ponta e depois nomeie o dono

Anote a tupla antes de testar: origem pretendida, endereço de destino, transporte, porta e a máquina dona do socket de escuta. Se qualquer elemento for um palpite, o teste não dirá nada útil, e você acabará mudando uma segunda camada para explicar a primeira.

Depois teste esse único caminho autorizado com a autenticação do aplicativo intacta. Evite publicar um listener amplo ou desligar controles não relacionados só para fazer uma verificação ambígua de endereço público responder, porque as duas mudanças sobrevivem ao teste e nenhuma prova que o projeto funciona.

O subsistema de tethering do Android encaminha o tráfego de downstream pelo próprio caminho, separado da captura normal de VPN por aplicativos, então um navegador funcionando em um laptop conectado não diz nada sobre acesso de entrada a um serviço no telefone. Antes de considerá-lo funcionando:

• O socket de escuta está em um endereço que o par pretendido consegue alcançar, não no loopback.
• O par está usando o endereço que pertence a esse ponto de entrada, não o endereço de saída de uma página de status.
• Qualquer mapeamento do lado da operadora ou do provedor é um recurso suportado, não uma regra que você adicionou localmente.
• Solicitação e resposta percorrem o mesmo contexto de rede, e a autenticação do aplicativo ainda passa.