O perfil OpenVPN do Windows falha no Ubuntu: três camadas

Inicie o mesmo perfil a partir do terminal e a mensagem que a maioria das pessoas copia é um aviso, não o motivo de o cliente ter parado. Aqui falham três camadas independentes: uma diretiva enviada que a compilação para Linux não implementa, os direitos necessários para criar um dispositivo tun e o auxiliar de resolução que transforma uma conexão num DNS funcional. Trate-as por ordem, porque cada uma pode esconder a seguinte.

Guarde o download tal como chegou e edite uma cópia, para que um novo download não reverta as suas alterações em silêncio.

Leia o aviso antes de o culpar

block-outside-dns bloqueia o DNS no Windows através da Plataforma de Filtragem do Windows, e o cliente Linux não tem a que o associar. Quando o servidor o envia, o cliente imprime uma linha de opção desconhecida para essa entrada enviada e continua, porque uma opção enviada não é tratada como fatal. A mesma linha no seu próprio ficheiro é outra coisa: aí o analisador pára. Decida qual das duas tem antes de tocar em qualquer coisa, porque só uma delas termina a execução.

Para remover o ruído, filtre-o antes da análise: uma entrada pull-filter ignore para esse nome, ou --ignore-unknown-option quando a linha está no ficheiro local. Ambas silenciam uma linha que já leu; nenhuma repara uma falha que não diagnosticou.

Os privilégios falham antes de tudo o resto

Um dispositivo tun e as rotas que o acompanham são objetos privilegiados, e uma conta normal não os consegue criar. A opção --user explica essa divisão: o daemon só abdica dos seus privilégios depois de o trabalho privilegiado estar feito. Inicie-o como root, ou através de uma unit que o inicie assim, e procure depois um erro de permissões antes de olhar para os certificados. Afrouxar as permissões do ficheiro do perfil não dá ao processo os direitos de que ele carece.

Um erro de TLS significa que o cliente passou desta camada. Uma queixa sobre o dispositivo ou a rota significa que nunca chegou à camada de cima.

O que a GUI faz e o terminal não

Ligar-se com sucesso enquanto todas as consultas continuam a falhar é a terceira camada. O NetworkManager faz o seu próprio trabalho de resolução, e é por isso que uma importação a partir do ambiente de trabalho pode distribuir DNS mesmo quando o script up do perfil nunca correu com sucesso. O comando openvpn --config executa o que --up nomear, e se esse auxiliar faltar, a interface aparece enquanto as consultas continuam a ir para os servidores anteriores. Compare os scripts dos dois caminhos antes de instalar seja o que for.

Use o auxiliar empacotado para a sua distribuição; um script copiado de uma publicação de blogue normalmente visa outro resolvedor. A integração fornecida para o systemd-resolved não é o script genérico ao estilo vpnc, e cada uma espera os seus próprios argumentos e variáveis do cliente. Os scripts up definidos pelo utilizador também exigem script-security 2 antes de o cliente os executar.

Separe as camadas na próxima execução

Execute uma vez com --verb 4 e leia o registo pela ordem em que aconteceu: criação do dispositivo, rotas, aperto de mão TLS e depois a saída do script up. A primeira falha nessa sequência é a que vale a pena corrigir; tudo o que vem depois costuma ser uma consequência. Um túnel que se estabelece enquanto o resolvedor não o faz coloca-o na terceira camada, onde o certificado é irrelevante. Deixe o perfil descarregado intacto enquanto compara.

Quando cada ajuste do operador produz mais uma linha rejeitada, o ficheiro está dirigido a outra plataforma. Peça uma exportação para Linux em vez de construir uma lista de filtros permanente.

Anote que camada falhou e o que a mudou, porque a próxima pessoa que receber o mesmo ficheiro também vai parar ao aviso.