Portabilidade do perfil OpenVPN: chaves portáveis versus opções de plataforma

O mesmo ficheiro .ovpn abre um túnel num cliente e não arranca noutro, e o certificado é normalmente o primeiro suspeito. Mais frequentemente o ficheiro contém uma diretiva que só um motor implementa. Um perfil é um contrato com um cliente específico, não um script portável.

Separe o que viaja com a identidade do que pertence a uma plataforma. Então a falha costuma nomear-se sozinha.

Um ficheiro, dois contratos

Um perfil reúne três tipos de conteúdo: material de identidade como os certificados CA e de cliente e a chave privada, factos de transporte como o ponto final remoto e o protocolo, e diretivas de comportamento como o tratamento de DNS ou opções de dispositivo. Os dois primeiros são amplamente portáveis entre motores que suportam o mesmo protocolo. O terceiro é onde as implementações divergem. Tratar o ficheiro inteiro como uma única unidade portável é o que produz as falhas confusas.

Um ficheiro que funciona numa GUI numa plataforma não é automaticamente válido para o cliente de linha de comandos noutra. Mesmo quando ambos são OpenVPN, os analisadores e os conjuntos de opções diferem. Por isso uma importação bem-sucedida não é prova de um perfil portável.

Material portável versus diretivas de plataforma

As secções de identidade e transporte são a parte a preservar. ca, cert, key e remote descrevem quem se liga e para onde, e significam o mesmo para qualquer cliente conforme.

As diretivas de comportamento são a parte a comparar. block-outside-dns, por exemplo, existe para alterar o comportamento de DNS no Windows. Um cliente Unix pode não a reconhecer de todo.

Leia a lista de opções do cliente recetor em vez da do emissor. O manual de referência do OpenVPN 2.6 documenta as opções do motor, e a caixa de importação de uma GUI não é essa lista.

Leia o erro do analisador antes do certificado

Um erro que nomeia uma opção não reconhecida é uma falha do analisador, não uma falha de autenticação. A ligação nunca chegou a TLS, por isso mudar certificados não pode ajudar. Leia o primeiro erro do cliente e da versão reais e depois remova ou substitua apenas a diretiva que esse cliente não consegue implementar. Apagar secções de certificado ou de rotas para o ficheiro carregar é a forma como um perfil funcional se torna inseguro.

Se o erro mencionar o handshake, um certificado ou uma cifra, o perfil foi analisado e o problema está noutro sítio.

Guarde o ficheiro original junto do adaptado. Quando o ficheiro adaptado falhar mais tarde, o original é o controlo que diz se mudou a alteração ou o ambiente.

Os privilégios são uma segunda fronteira

Os privilégios são a outra fronteira: criar um dispositivo de túnel, instalar rotas e ler uma chave privada dependem todos de permissões locais. Um ficheiro de chave legível apenas pelo root é uma implementação normal, não um defeito do perfil. A correção pertence à propriedade ou às capacidades, não ao ficheiro.

Executar o cliente com sudo pode resolver uma recusa de permissão local, e não pode acrescentar uma diretiva que o binário não implementa. Também altera que porta-chaves, caminhos de configuração e contexto de gestor de rede se aplicam, pelo que o resultado não é o mesmo teste.

Adapte com critério

Quando um fornecedor publica perfis separados, escolha o destinado ao cliente recetor. Adaptar o ficheiro de outra plataforma é o último recurso. Exige um registo de cada opção alterada e uma cópia do original.

Teste a identidade, o encaminhamento e o DNS como três resultados separados. Um perfil que se autentica e encaminha mas quebra a resolução de nomes é um perfil parcialmente adaptado, não um que funciona.