OpenVPN TAP no macOS: verifique o cliente antes de depurar

Um perfil antigo chega a um Mac atual, o cliente importa-o sem queixa e a ligação cai ou nunca deixa passar tráfego. Antes de gastar uma tarde em certificados, leia a linha de dispositivo do perfil. Se disser dev tap, está a pedir ao cliente uma interface ao estilo Ethernet e, no macOS, é nesse pedido que terminam a maioria destas sessões.

Passo 1: confirme que o perfil pede mesmo TAP

Os perfis são renomeados, envolvidos e exportados de novo, por isso verifique o ficheiro que realmente importou. Procure a diretiva de dispositivo e qualquer include que a possa substituir. Duas linhas de saída resolvem a questão na maioria dos casos. Quando aparecem tanto dev como dev-type, ganha a diretiva posterior, e é exatamente esse tipo de detalhe que um perfil copiado esconde.

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

Se o ficheiro contiver dev tap ou dev tap0, o cliente tem de implementar uma interface TAP. Se contiver dev tun, o resto deste artigo não se aplica e a falha está noutro sítio.

Anote o nome e a versão do cliente, a versão de macOS e a origem do perfil. Esses três factos decidem qual dos dois caminhos abaixo é sequer possível.

Passo 2: saiba o que o modo de dispositivo muda realmente

Uma interface TUN transporta pacotes IP. O cliente lê e escreve pacotes endereçados a um par IP, e o sistema operativo encaminha-os como qualquer outra interface.

Uma interface TAP transporta tramas Ethernet, incluindo difusão e ARP. É isso que permite a um servidor em ponte distribuir endereços por DHCP e a um cliente descobrir dispositivos aos gritos, e por isso alguns desenhos antigos dependem disso.

O custo é que o TAP precisa de um controlador que apresente ao sistema uma interface Ethernet. A Apple descontinuou o modelo de extensão do kernel em que se baseavam os controladores TAP antigos para Mac, e a sua API substituta não aparece por magia dentro de clientes que nunca foram atualizados para a usar. Uma capacidade de plataforma e um produto já entregue são coisas distintas.

Passo 3: escolha entre um cliente compatível e uma migração

Há dois caminhos honestos. O primeiro é um cliente cujo editor declara, para a sua versão de macOS e o seu hardware, que suporta a disposição TAP de que precisa. Não uma publicação de fórum de há quatro anos nem um instalador arquivado: uma declaração atual mais uma ligação de teste.

O segundo é mudar o serviço para TUN, o que é tanto uma mudança de servidor como de cliente. Requer uma topologia encaminhada, um conjunto de endereços, rotas empurradas para as redes remotas e um caminho de regresso dessas redes ao conjunto.

O que não funciona é editar tap para tun na cópia local e esperar. O servidor continua a fazer ponte, o cliente agora fala IP e nada concorda.

Passo 4: reúna os factos antes de mudar um serviço que funciona

Deixe o perfil original intacto e faça uma cópia para experiências. Um ficheiro que pode restaurar num minuto vale mais do que uma pasta arrumada. Quando o substituto funcionar, apague a cópia de propósito em vez de deixar dois perfis que parecem idênticos numa lista. Esse único hábito evita a maior parte da confusão que se segue a uma migração falhada. Registe o comportamento atual para poder provar o que mudou: o túnel sobe, recebe um endereço, consegue chegar a um anfitrião conhecido e a resolução de nomes funciona.

Faça três perguntas ao proprietário da gateway. O servidor corre uma topologia em ponte ou encaminhada? Que prefixos remotos devem ser acessíveis? E há uma janela de manutenção para mudar a configuração, ou espera-se que funcione sem tocar no servidor?

As respostas determinam se esta tarde resolve um problema de cliente ou se para a semana planeia uma mudança de rede.

Passo 5: verifique a migração dos dois lados

Quando o servidor tiver uma configuração encaminhada e você tiver um perfil adequado, teste nesta ordem: o túnel estabelece-se, o cliente recebe um endereço do novo conjunto, um anfitrião do lado remoto responde e um nome resolve-se através da definição DNS empurrada.

Depois teste o que antes dependia do comportamento Ethernet. Se uma aplicação descobria dispositivos por difusão, não os encontrará por um túnel encaminhado, e nenhuma configuração de cliente traz isso de volta. Essa aplicação precisa de um endereço conhecido, de um anfitrião auxiliar local ou de outro método de descoberta.

Termine com uma reconexão e um reinício, porque um perfil que só funciona à primeira tentativa normalmente significa que as rotas empurradas ou a definição DNS não são aplicadas ao reconectar.

Quando continua a falhar, leia o primeiro erro

Um cliente que não consegue criar a interface di-lo no registo, normalmente nas primeiras linhas. Um cliente que a cria e depois não consegue autenticar-se já passou há muito a questão do dispositivo, e continuar a perseguir TAP desperdiça a sessão.

Guarde o perfil original e a configuração que funciona até o substituto estar provado. Reverter uma alteração de cliente é rápido; reconstruir uma rede em ponte que alguém desmontou por intuição não é.