O OpenVPN rejeita a primeira linha? O ficheiro é provavelmente UTF-16

O erro aponta para a primeira linha de um ficheiro .ovpn e cita algo que parece letras baralhadas onde deveria estar client. O ficheiro abre sem problemas no seu editor, a primeira linha lê client, e a diretiva é completamente comum. Ambas as observações são verdadeiras, porque o editor descodifica os bytes e o cliente não. O que está a ver é quase sempre um problema de codificação, não de sintaxe.

O mito: o editor mostra-lhe o ficheiro

Um editor de texto descodifica bytes em caracteres com uma codificação que ou deteta ou adivinha. Quando adivinha UTF-16, o ficheiro parece perfeito no ecrã enquanto os bytes por baixo são pares, com um byte zero depois de cada letra latina. OpenVPN lê esses bytes como caracteres, e a discrepância aparece na primeira diretiva que tenta analisar.

Assim, a linha visível e a linha entregue são duas coisas diferentes. Apagar os caracteres estranhos que vê é uma alteração na apresentação, não na codificação, e a análise seguinte falha pelo mesmo motivo com uma mensagem ligeiramente diferente. É por isso que perseguir o token do erro nunca leva a lado nenhum. Os bytes estão errados na origem, e cada leitor a jusante adivinha a mesma sequência quebrada.

Vale a pena reconhecer a forma concreta da falha, porque é diagnóstica de uma maneira específica. Um token logo no início do ficheiro, num perfil que de resto funcionou noutras máquinas, é uma questão de ordem dos bytes e não de vocabulário.

O que os primeiros bytes dizem realmente

Leia os bytes em vez dos caracteres. Dois comandos pequenos resolvem-no em segundos, e nenhum exige abrir o ficheiro numa aplicação que o possa alterar:

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

O padrão que procura é um par de bytes iniciais seguido de texto em que cada segundo byte é zero. FF FE indica UTF-16 little-endian, FE FF indica big-endian e EF BB BF indica UTF-8 com marca de ordem de bytes. Um ficheiro UTF-8 comum sem marca começa diretamente no byte da primeira letra.

Os bytes zero entre letras são a pista. Em UTF-16 little-endian a palavra client ocupa doze bytes em vez de seis, porque cada caráter ASCII é seguido de um zero. Essa estrutura não é algo que o ecrã de um editor lhe possa mostrar, nem algo que um apagamento de dois bytes consiga remover.

Há aqui uma nuance importante: o leitor de configuração do OpenVPN salta de facto uma marca de ordem de bytes UTF-8 no início de um ficheiro, como mostra o leitor de configuração 2.6. Essa tolerância é específica dessa marca e não faz nada por um ficheiro UTF-16 cujas letras estão preenchidas com zeros. Tratar as duas marcas como o mesmo problema é a segunda metade do mito.

Converter é guardar como, não apagar

Guarde uma cópia intacta do original do operador antes de fazer qualquer coisa e trabalhe num ficheiro separado. Um perfil pode conter uma chave privada ou material de conta, pelo que a cópia é tanto o seu retrocesso como a sua referência.

Depois faça uma conversão de codificação real, seja pelo menu explícito de codificação do editor, seja com um conversor que declare a codificação de entrada e de saída:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

Verifique o resultado em vez de confiar no estado de saída do comando. A conversão deve preservar cada diretiva, e tem de preservar qualquer bloco de certificado ou chave incorporado byte a byte dentro das suas marcas. Voltar a embrulhar dados PEM, alterar as terminações de linha dentro de um bloco ou reformatar o perfil durante a conversão cria um problema novo enquanto corrige o antigo.

Aponte o cliente ou o serviço para o ficheiro convertido e veja o primeiro erro que ele reporta. Se o token baralhado desapareceu, o trabalho de codificação está feito e tudo o que falhar depois é outra questão.

O que uma codificação corrigida não corrige

A codificação determina como o texto é lido; não diz nada sobre se as opções são válidas para o cliente à sua frente. Um perfil exportado para outra implementação pode ser analisado sem erros e ainda assim ser rejeitado por causa de uma opção que a compilação em execução não suporta, ou de uma diretiva cujo argumento significa outra coisa naquele cliente.

Esses erros posteriores merecem a sua própria investigação: a ortografia exata, a sintaxe do argumento e a versão que o aceita. Não trate uma análise bem-sucedida como um perfil bem-sucedido.

Mantenha a investigação local enquanto está nisso. Os conversores públicos online e os despejos hex colados são um mau lugar para um ficheiro que pode conter uma chave privada, porque o problema de codificação é fácil de corrigir e uma chave divulgada não.