Motor OpenVPN ou Tunnelblick: quem é dono da sessão VPN do Mac?

O Homebrew instala um programa OpenVPN; o Tunnelblick instala um gestor que executa um ou mais motores. São camadas diferentes, e a pergunta útil não é se gosta de usar um terminal. É quem é dono da configuração, das alterações de DNS, do pedido de credenciais e da limpeza no fim da sessão. Um único proprietário para essas camadas é o que torna a configuração previsível.

Percorra as cinco verificações abaixo por ordem. A primeira que tem dois proprietários é a que produz os estranhos estados semiconectados que as pessoas atribuem ao próprio OpenVPN. Cada verificação nomeia a evidência que a resolve.

Verificação um: qual binário do OpenVPN está realmente em execução

Execute pgrep -fl openvpn enquanto está ligado e leia a linha de comando completa. O primeiro caminho é o motor que está realmente em execução. No Apple Silicon, uma instalação do Homebrew costuma ficar em /opt/homebrew, enquanto os Mac Intel usam /usr/local, e o Tunnelblick executa um motor de dentro do seu próprio pacote de aplicação.

O Tunnelblick inclui motores e permite que uma configuração escolha um. Atualizar a fórmula do Homebrew altera o binário autónomo, não o motor que um perfil do Tunnelblick inicia. Se compara versões para explicar uma diferença de comportamento, compare o motor da lista de processos e não o do gestor de pacotes. A cadeia de versão sozinha não lhe diz que perfil esse motor carregou.

Um perfil copiado também pode fazer dois motores parecerem idênticos enquanto leem ficheiros diferentes. O caminho do perfil na linha de comando diz que configuração o processo em execução carregou; um perfil aberto num editor não é evidência. Compare esse caminho antes de comparar comportamentos.

Verificação dois: quem altera o DNS e as rotas

O motor pode executar as diretivas up e down do próprio OpenVPN, mas o gestor pode ser dono do mesmo ciclo de vida. As definições de servidor de nomes do Tunnelblick controlam os seus scripts padrão de ligação e desligação, e quando essa integração está ativa, as diretivas concorrentes do perfil podem ser ignoradas.

Isso importa porque o DNS é o local onde um túnel a funcionar parece avariado com mais frequência. Verifique scutil --dns enquanto está ligado, anote qual é o primeiro resolver e confirme que ele regressa após a desligação. Se o perfil espera definir o DNS sozinho enquanto o gestor também o gere, um dos dois perde.

Decida que camada é dona do DNS antes da primeira ligação e depois remova a diretiva perdedora em vez de deixar as duas. As alterações de rota seguem a mesma regra: um proprietário, visível na configuração, com um caminho de reposição documentado.

Verificação três: de onde vêm as credenciais

Um pedido interativo e um processo sem supervisão têm requisitos diferentes. Uma credencial guardada por uma aplicação não fica automaticamente disponível para outro processo, e um item do porta-chaves limitado ao gestor pode ser invisível para um motor autónomo iniciado a partir de uma shell.

Liste a fonte de credenciais do perfil: um certificado e uma chave de cliente, um pedido de nome de utilizador e palavra-passe, ou um token fornecido por um assistente externo. Depois confirme que o proprietário escolhido consegue chegar a essa fonte sem uma pessoa se a ligação tiver de sobreviver a um reinício.

Verificação quatro: quem inicia, supervisiona e para o processo

Uma implementação autónoma precisa de um supervisor se tiver de permanecer ativa. O Launchd pode iniciar o motor no início de sessão ou a pedido, reiniciá-lo após uma falha e pará-lo de forma limpa, mas alguém tem de escrever e ser dono dessa tarefa. Executar o comando num terminal funciona para um teste e não para um utilizador que fecha a janela.

Se o Tunnelblick continuar a ser o proprietário, use os controlos suportados em vez de iniciar um segundo motor. O binário do Homebrew, com um perfil copiado, abre uma ligação independente com a sua própria configuração e contexto de integração em vez de comandar a sessão do Tunnelblick existente.

Seja qual for o proprietário escolhido, defina o que acontece em suspensão, mudança de rede e fim de sessão. Um gestor trata normalmente desses eventos; um processo nu normalmente não, e a rota ou o resolver obsoletos resultantes são facilmente mal interpretados como uma falha do servidor.

Verificação cinco: como a transferência é verificada

Teste o novo proprietário com o antigo desativado e depois teste novamente o antigo se pensar mantê-lo. Um recurso privado que responde num fluxo de trabalho e não no outro é evidência da integração em falta, não do servidor.

Para uma transferência para um motor autónomo, registe o caminho do perfil, o caminho do binário, o supervisor, o proprietário do DNS e a fonte de credenciais. Depois verifique o recurso privado, o caminho para a internet pública e uma desligação limpa nessa ordem. Se o DNS ou as rotas permanecerem após a desligação, o novo proprietário não terminou.

Para uma transferência para o Tunnelblick, selecione o motor para a configuração, ative a integração DNS que pretende e remova as diretivas do perfil que se lhe opõem. Depois repita as mesmas três verificações. Uma ligação que funciona mas deixa o resolver alterado é uma transferência falhada, mesmo que o túnel tenha subido.

O empacotamento não resolve a compatibilidade com o servidor. Verifique os requisitos de cliente do próprio serviço e escolha o motor sozinho apenas quando tenciona fornecer a sua gestão.