Como testar um segundo cliente VPN no Mac sem perder o primeiro

Você instala o segundo cliente para compará-lo, e o primeiro deixa de funcionar. Nada foi apagado, e as duas aplicações continuam instaladas. O que mudou está por baixo deles: uma extensão de sistema, uma definição de DNS ou uma rota predefinida, e os dois clientes já não concordam sobre quem é o proprietário. A instalação não é a parte arriscada; a parte arriscada é executar ambos sem uma linha de base registada para a qual voltar.

O sintoma: a configuração que funcionava pára após a segunda instalação

Os clientes VPN modernos do macOS frequentemente fornecem uma extensão de rede em vez de uma interface ao estilo antigo. Instalar uma pode pedir aprovação, adicionar um perfil de configuração ou registar uma extensão de sistema que influencia o tráfego antes de qualquer ligação ser feita. A extensão carrega antes de a janela da aplicação aparecer, e é por isso que o cliente original pode falhar enquanto o novo fica inativo.

Se depois o cliente original não conseguir ligar-se, ou ligar-se e não resolver nada, a nova extensão é o primeiro suspeito. Isso não é prova de um conflito, mas é onde a investigação começa. A seguir, verifique a lista de extensões e os perfis de configuração instalados, não apenas a pasta de aplicações.

Registe a linha de base antes de instalar qualquer coisa

Anote o que funciona agora: o resultado da aplicação, a versão do cliente, o ponto final a que se liga e quaisquer exclusões por aplicação ou de túnel dividido. Guarde o perfil original através do processo protegido que o cliente suporta, e não copiando ficheiros de um pacote de aplicação.

scutil --dns | head -40
netstat -rn | head -30
ifconfig | grep -E "^(utun|ipsec)"

Capture essas três saídas enquanto o cliente que funciona está ligado. Elas dão-lhe o estado do resolver, a tabela de rotas e a lista de interfaces que uma configuração funcional produz, e é exatamente disso que precisa para a comparação posterior. Se o Mac for gerido por um empregador, confirme antes de começar que a comparação é permitida, porque uma ligação de trabalho automática pode reativar-se durante o teste e o resultado deixa então de representar qualquer dos clientes isoladamente. Guarde as três saídas junto à nota do perfil para que a comparação posterior tenha uma referência.

Mude um caminho ativo de cada vez

Pare a ligação original com o seu controlo habitual e depois inicie a alternativa. Dois clientes ligados ao mesmo tempo produzem um resultado que descreve a combinação, e não qualquer dos produtos. Mantenha o ponto final e a tarefa comparáveis se os serviços o permitirem, porque um download mais rápido através de outro servidor compara duas opções de ligação e não duas aplicações.

Se o novo cliente falhar, preserve o primeiro erro antes de mudar qualquer outra coisa. O primeiro erro costuma indicar a etapa, e uma segunda tentativa após uma alteração de definições relata muitas vezes algo menos útil.

Compare DNS, rotas e a aplicação, não apenas a velocidade

Execute os mesmos três comandos com o novo cliente ligado e compare-os linha a linha. Um resolver que aponta para outro sítio, ou uma tabela de rotas sem a sub-rede privada, explica a maioria das diferenças de comportamento antes de olhar para o débito. Depois teste a aplicação real com a mesma tarefa, porque um cliente que liga depressa e não resolve um nome interno não ganhou a comparação mesmo que a janela de estado pareça melhor.

Note qual interface o tráfego usou. No macOS o nome da interface do túnel não é um indicador fiável de qual cliente possui a rota, por isso combine a lista de interfaces com a tabela de rotas em vez de ler apenas uma delas. Se existirem duas interfaces utun, a que transporta o seu tráfego é a que tem uma rota correspondente e uma entrada no resolver. Adivinhar pelo nome é como a interface errada acaba culpada, porque a interface que existe nem sempre é a que transporta o tráfego.

Leia as três saídas em vez de as percorrer. No dump do resolver, um servidor de nomes ligado a uma interface utun mostra qual cliente o instalou; na tabela de rotas, a rota predefinida nomeia a interface que transporta o tráfego; na lista de interfaces, um segundo dispositivo utun significa que foi criado um segundo túnel. Essas três linhas, comparadas com a linha de base, separam uma configuração recuperada de outra em que os dois clientes ainda competem.

Restaure e depois remova de forma limpa

Volte pelo fluxo de trabalho próprio do cliente original e confirme que as saídas da linha de base correspondem ao que registou. Se o resolver ou a tabela de rotas não recuperar, pare e corrija isso antes de remover qualquer outra coisa. Remova a configuração não utilizada através do componente que a possui: o desinstalador do cliente, o perfil ou as definições da extensão de sistema.

Termine atualizando as suas notas com a versão testada, o ponto final utilizado e o resultado de cada um. Seis meses depois, esse registo é a diferença entre uma decisão e um rumor.