OpenVPN no Android não adiciona rota sem endereço de túnel

Seu perfil OpenVPN no Android não adiciona uma rota porque o telefone não tem endereço na interface virtual, então não há nada para onde uma rota aponte. As rotas respondem apenas para onde os pacotes devem ir. O endereço de túnel responde quem é o telefone dentro do túnel, e o cliente precisa fornecer um antes que a interface possa existir. Percorra as quatro verificações abaixo em ordem e pare na primeira falha, porque editar rotas antes de o endereço existir esconde o problema real.

Leia a falha na ordem em que o cliente a executa

O VpnService.Builder do Android mantém os dois conceitos separados: addAddress() coloca um endereço na interface que o aplicativo está construindo, addRoute() adiciona um prefixo de destino e establish() recusa criar a interface até que pelo menos um endereço tenha sido adicionado. Um cliente OpenVPN mapeia o perfil e as opções enviadas pelo servidor exatamente nessas chamadas, então uma conexão que nunca analisa um endereço não consegue construir a interface de modo algum.

É por isso que a linha de log que você está lendo pode nomear uma rota enquanto a causa está um passo antes. O cliente só chega à fase da rota depois que a interface existe; sem endereço, a chamada de rota falha imediatamente ou nunca é executada. Quando o log diz que não consegue adicionar uma rota, comece pelo endereço e não pela sintaxe da rota.

Verificação 1: o servidor coloca um endereço na resposta?

Num serviço OpenVPN encaminhado, o endereço vem do conjunto do servidor ou de uma atribuição por cliente, e a topologia decide a forma que ele tem. Num servidor OpenVPN 2.4 ou posterior, um serviço com topologia de sub-rede é assim:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Com essa forma o servidor envia algo como ifconfig 10.8.0.6 255.255.255.0. Uma implantação mais antiga com topology net30 envia, em vez disso, um endereço de par, por exemplo ifconfig 10.8.0.6 10.8.0.5, então um perfil movido entre os dois modelos pode parecer correto embora carregue a máscara de rede errada.

Procure no log de conexão do cliente o conjunto de opções enviadas. Se não houver nele nenhuma linha ifconfig, o servidor nunca enviou um endereço ou o cliente recusou a opção. Num servidor que usa client-config-dir, o arquivo nomeado segundo o common name do certificado precisa existir e conter a atribuição:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Verificação 2: o cliente mantém o endereço que recebeu?

Um filtro amplo demais é a segunda causa comum. pull-filter existe no OpenVPN 2.4 e posteriores, e quando vários filtros correspondem à mesma opção vence o último que corresponde, então um catch-all no fim remove o endereço sem erro:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Restrinja o filtro à opção da qual você realmente quer se livrar e deixe o endereço em paz:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

O conselho de desativar todos os pull costuma vir de alguém que quer se livrar de uma única rota. route-nopull é o interruptor mais estreito: mantém o ifconfig e as demais opções enviadas enquanto recusa rotas enviadas e opções do tipo DHCP. Use-o quando for realmente isso que você quer, e responda à questão do endereço separadamente.

Verificação 3: o endereço é seu para digitar?

O endereçamento manual só é legítimo quando o operador entrega o valor a você. Se você digitar um por conta própria, ele precisa vir da sub-rede do cliente VPN, ser único entre as sessões ativas e corresponder à topologia que o servidor executa. Copiar o endereço de uma ponte de desktop ou de um host na LAN remota falha nos dois pontos: o telefone reivindicaria um endereço que já existe em outro lugar, e o gateway não teria caminho de volta até ele.

O prefixo da LAN remota numa rota é um destino, nunca a identidade do telefone. Uma rota para 10.60.0.0/24 diz para alcançar essa rede pelo túnel; ela não diz nada sobre qual endereço 10.60.0.x o telefone deveria ter, e o telefone não deveria ter nenhum deles. As atribuições estáticas pertencem ao lado do servidor, onde não podem colidir com o conjunto dinâmico.

Duas sessões numa mesma identidade expõem a mesma colisão. Se o mesmo certificado se conecta duas vezes e o servidor envia um endereço fixo para ambas, a segunda sessão duplica a primeira, e a solução são identidades separadas ou atribuições separadas, não uma edição no lado do cliente.

Verificação 4: algo mais ocupa a vaga do túnel?

O Android permite apenas um serviço VPN ativo por vez. Outro aplicativo VPN, ou uma entrada de VPN sempre ativa deixada habilitada para um perfil que já não funciona, pode ocupar essa vaga antes que seu cliente OpenVPN chame establish(). A interface então nunca aparece mesmo que o perfil seja válido, então desconecte a outra VPN, desligue a configuração de sempre ativa e reconecte antes de tocar no perfil.

Um serviço que exige ponte Ethernet é o outro beco sem saída. Um aplicativo Android sem root pode criar um túnel IP, não um segmento Ethernet com ponte, então nenhum endereço que você digite fará um servidor dev tap funcionar; o operador precisa oferecer um serviço encaminhado. Ao relatar o problema, inclua o nome e a versão do cliente, o conjunto de opções enviadas, a topologia e o passo exato em que o endereço deveria ter aparecido.

Se as quatro verificações passarem e o endereço estiver presente, único e corretamente mascarado, a questão da rota passa a ser a comum: quais prefixos o servidor autoriza e como o cliente deve delimitá-los. Anote o endereço do túnel, a máscara de rede e a topologia antes de mudar qualquer outra coisa, porque são esses três valores que o operador precisa comparar com a visão do servidor.