Servidor VPN no Android: root não torna o telefone alcançável

O root muda quais operações de rede um processo pode tentar. Não dá ao telefone um endereço alcançável publicamente, não reserva um mapeamento de entrada na operadora nem mantém um daemon vivo após reiniciar. Se está a decidir se um telefone Android pode servir como servidor VPN, separe três perguntas: o cliente previsto consegue chegar ao listener, que modelo de privilégios a implementação do servidor exige e o que tem de ser encaminhado depois de o túnel estar levantado.

Quem tem de chegar ao telefone, e a partir de onde

Um cliente na mesma LAN permitida e um cliente em dados móveis testam duas redes diferentes. Resolva primeiro a prevista, porque as respostas não se transferem. Em Wi-Fi, o tráfego de entrada não solicitado costuma precisar de um mapeamento no router a montante e de um caminho público utilizável para lá dele. Em rede móvel, o NAT de nível de operadora faz com que o IPv4 de entrada fique frequentemente indisponível, faça o telefone o que fizer.

É exatamente esse último ponto que o root não consegue tocar. A firewall local do telefone e o NAT da operadora são sistemas diferentes, e mudar o primeiro não tem efeito sobre o segundo. Um endereço de interface privado, um ícone de dados móveis ou um socket à escuta não são prova de alcançabilidade. Se o caminho da operadora oferecer mesmo IPv6 encaminhável globalmente, continua a precisar de uma política deliberada de listener e de firewall para ele; ter um endereço não é o mesmo que aceitar ligações.

Servir e encaminhar são dois êxitos diferentes

Um handshake VPN concluído prova que o túnel existe. Não prova que o cliente chega a uma LAN atrás do telefone, nem que o telefone pode servir de saída para a internet. São configurações separadas, construídas sobre o plano de endereços interno, as rotas, o comportamento de retorno e uma política de encaminhamento estreita para a tarefa que realmente quer.

O modo de falha é previsível: o handshake tem sucesso, o cliente mostra ligado e nada carrega. Antes de depurar o cliente, decida qual dos dois papéis está a construir. O acesso remoto a um dispositivo na rede do telefone e a saída para a internet por túnel completo exigem regras de encaminhamento diferentes, e conceder ambas quando queria uma alarga a exposição sem acrescentar a capacidade pedida.

O modelo de privilégios é uma escolha, não root ou nada

Um daemon OpenVPN convencional que usa um dispositivo TUN do kernel precisa das capacidades correspondentes, de acesso ao nó do dispositivo e da cooperação da política de segurança do Android. O root não é uma isenção geral do SELinux; um processo privilegiado continua limitado pela política da plataforma. É por isso que um binário que corre bem num servidor Linux pode falhar num telefone sem um erro evidente sobre permissões.

Uma implementação de gateway em espaço de utilizador pode ter um modelo de privilégios completamente diferente, pelo que a afirmação comum de que todo o servidor VPN no Android precisa de root é demasiado lata. O que o root compra é a capacidade de tentar mais operações, não a garantia de que sejam permitidas ou de que o resultado seja alcançável.

O próprio registo do serviço VPN do Android é ainda outro mecanismo. Dá a uma aplicação uma interface de cliente gerida com um ciclo de vida definido; não é um instalador de servidores genérico, e iniciar um daemon a partir de um terminal não lhe dá gestão permanente, política por aplicação nem um caminho de recuperação próprio.

Se quer um ponto de saída, mude a arquitetura

Quando o objetivo é simplesmente uma saída remota para a internet através do telefone e não a compatibilidade com um perfil OpenVPN existente, um nó de saída suportado numa rede sobreposta é o desenho mais adequado. A Tailscale documenta um papel de nó de saída para Android com os seus próprios passos de registo, autorização e seleção de cliente.

A troca é real e vale a pena dizer com clareza: aceita outro protocolo, outro modelo de confiança e uma dependência dessa conta e serviço de coordenação. Não faz com que um cliente OpenVPN não modificado se junte à rede sobreposta, e não lhe dá um listener OpenVPN num endereço público.

O que a implementação ainda precisa

Qualquer que seja o caminho, o básico operacional decide se sobrevive uma semana. Mantenha as credenciais do servidor privadas, emita identidades de cliente distintas e planeie a revogação antes de precisar dela. Decida como chegam as atualizações, o que mantém o serviço a correr em segundo plano e como recupera após um reinício ou uma mudança de rede.

Evite os atalhos que parecem cómodos: um binário estático obsoleto, nomes de interface codificados a martelo e um script de arranque que esvazia a política de firewall existente. Depois aceite o resultado apenas perante um teste concreto: um cliente remoto autorizado chega ao recurso previsto, os destinos proibidos continuam indisponíveis e o dispositivo volta sozinho após o evento de ciclo de vida suportado. O acesso root é um ingrediente possível desse resultado, e raramente o decisivo.