TAP ou TUN? Clientes OpenVPN Android e servidores com bridge

Um perfil que funciona num portátil falha no telemóvel. O passo óbvio é editar uma palavra na configuração do cliente. Essa palavra não vai ajudar, porque as duas extremidades não falam do mesmo tipo de tráfego.

O TAP transporta quadros Ethernet. O TUN transporta pacotes IP. A uma aplicação VPN Android é entregue uma interface IP, o que torna uma das duas disposições possível e a outra não, diga o que disser a configuração.

A comparação é curta, mas decide se pode corrigir isto no telemóvel ou se tem de mudar o serviço.

Dois tipos de túnel com cargas diferentes

Uma interface TAP comporta-se como um adaptador Ethernet. Transporta quadros, ou seja ARP, difusão e tudo o resto que uma LAN transporta abaixo de IP. É isso que torna a ponte possível: o túnel estende um domínio de difusão e os clientes comportam-se como se estivessem ligados a um comutador.

Uma interface TUN transporta pacotes IP endereçados a ela. Não há camada de ligação para negociar, nem ARP, nem difusão. O encaminhamento decide o que entra no túnel, e a configuração do lado do servidor usa uma sub-rede em vez de uma ponte.

Ambas as extremidades têm de concordar qual das duas estão a fazer. Trocar dev tap por dev tun de um lado não converte o serviço; produz um cliente que espera um túnel encaminhado e um servidor que continua a enviar quadros, e o handshake pode ter sucesso enquanto nada de utilizável passa.

O que o Android realmente entrega à aplicação

A API VpnService da plataforma dá a uma aplicação uma interface virtual para pacotes IP, configurada com endereços, rotas e uma MTU. Não há nenhum adaptador Ethernet nessa API, nem forma de a aplicação inventar um.

É por isso que o OpenVPN Connect documenta suporte para ligações TUN encaminhadas em Android e não para pontes TAP. As perguntas frequentes do Android são a declaração do lado do cliente sobre esse limite, e coincide com a API da plataforma.

Ferramentas de rede com root, firmware personalizado ou um produto que implemente uma camada de tradução explícita são outras disposições. O caso comum é aquele em torno do qual deve planear: uma aplicação que consiga importar o seu ficheiro e correr como utilizador normal, com uma interface IP e nada por baixo.

Como fica quando tenta de qualquer maneira

A ligação normalmente estabelece-se. É isso que torna a falha confusa: o cliente reporta ligado, o registo do servidor mostra um par, e nenhuma aplicação funciona.

O tráfego endereçado ao endereço atribuído ao telemóvel não chega, porque o servidor faz ponte de quadros para um endereço MAC que o telemóvel nunca teve. A descoberta dependente de difusão fica vazia. Se a LAN depende de DHCP através da ponte, o telemóvel não obtém uma concessão por essa via, e um endereço atribuído manualmente na sub-rede com ponte continua a não criar a interface em falta.

Alguns clientes falham mais cedo, na importação do perfil, quando veem um tipo de dispositivo que não conseguem implementar. Qualquer dos dois comportamentos significa o mesmo, e nenhum se corrige adicionando rotas, mudando o DNS ou alargando o intervalo de endereços do túnel.

O que o lado do servidor tem de mudar

A correção pertence a quem opera o serviço VPN, e normalmente é aditiva em vez de uma migração. Execute uma segunda instância OpenVPN com um dispositivo encaminhado, a sua própria sub-rede de clientes e uma configuração do lado do servidor que atribua endereços e empurre as rotas de que os telemóveis precisam. A instância com ponte existente continua a servir os dispositivos que precisam mesmo de Ethernet.

Dois detalhes tornam isto viável na prática. A LAN precisa de uma rota de retorno para a nova sub-rede de clientes, apontando para o anfitrião VPN, senão as respostas nunca voltam. E a firewall no anfitrião do túnel tem de reencaminhar entre a interface do túnel e a LAN, e é o passo que mais frequentemente se esquece quando um teste a partir do próprio anfitrião tem sucesso.

Se o operador não pode adicionar um serviço, a alternativa é um dispositivo que possa juntar-se à ponte, ou seja um portátil ou um router a agir em nome do telemóvel. É um contorno com o seu próprio custo de gestão, não uma configuração Android.

Decida a partir da aplicação, não do túnel

Pergunte a que o telemóvel tem realmente de chegar e depois mapeie. Uma partilha de ficheiros ou um site de intranet alcançado por nome ou endereço é um requisito IP, e um túnel encaminhado satisfá-lo assim que o DNS resolve o nome e a rota existe. Uma ferramenta de descoberta que percorre o domínio de difusão local não é um requisito IP, e nenhuma quantidade de encaminhamento o preencherá.

Essa tabela é também o pedido a enviar. Nomeie a aplicação, o endereço ou o nome que usa, e se depende da descoberta. Um operador pode agir sobre essa descrição, coisa que ninguém pode fazer sobre um telemóvel que não liga.

Por fim, mantenha o serviço TAP para os dispositivos que dele precisam em vez de fazer cada cliente imitar um adaptador LAN. Dois serviços com propósitos claros são mais fáceis de suportar do que um que funciona a meio para todos.