Tem um wg0.conf e um cliente que só aceita .ovpn, por isso alguém sugere converter o ficheiro. Renomeá-lo produz um perfil que o OpenVPN não consegue interpretar, e uma tradução cuidadosa campo a campo produz um que é interpretado e depois falha no handshake. A razão não é o formato do ficheiro. WireGuard e OpenVPN são protocolos diferentes, com handshakes diferentes, modelos de autenticação diferentes e ideias diferentes sobre o que é um peer. A conversão só funciona no sentido em que pode pedir um perfil OpenVPN a quem opera o outro lado.

O ficheiro que tem descreve um peer, não um perfil de ligação

Uma configuração WireGuard é curta porque o protocolo é assim: uma interface com uma chave privada e endereços, depois um ou mais peers com uma chave pública, um endpoint e uma lista AllowedIPs. Não há camada de negociação para configurar nem conjunto de cifras para escolher.

Um perfil OpenVPN é um cliente para um canal de controlo baseado em TLS, e é por isso que transporta referências de certificados ou credenciais e diretivas que descrevem como se autentica.

Porque é que um ficheiro traduzido continua a falhar no handshake

O WireGuard começa com um handshake baseado em Noise, ligado a chaves estáticas dos peers, e fica em silêncio a menos que a chave pública do peer já seja conhecida. O OpenVPN abre uma sessão TLS, verifica um certificado de servidor ou uma chave estática e depois autentica o utilizador com certificados, nome de utilizador e palavra-passe, ou ambos. Nada num ficheiro WireGuard descreve isto. Um ficheiro traduzido teria o endpoint certo e tudo o resto errado.

Reutilizar o endereço e a porta também não ajuda, porque o outro lado está à espera de um pacote diferente.

O que perguntar ao fornecedor

Se foi um fornecedor que deu o ficheiro WireGuard, pergunte se a mesma conta tem acesso a OpenVPN e peça esse perfil. Muitos têm, e chega com as suas próprias credenciais em vez de ser uma cópia alterada da primeira.

Se a resposta for não, a limitação é a subscrição e não o ficheiro, e nenhum conversor muda isso.

Se o router ou o cliente só fala OpenVPN

Quando o dispositivo que tem de ligar só suporta OpenVPN, verifique o suporte de protocolos documentado do outro lado antes de procurar outra extensão. Um router que termina OpenVPN não se deixa convencer a aceitar WireGuard por importar um ficheiro. As opções viáveis são um endpoint OpenVPN do lado do servidor ou outro dispositivo que fale WireGuard.

Escolha com base em quem administra o outro lado, não no ficheiro que por acaso tem.

Se gere o servidor, acrescente o protocolo

Suportar um segundo protocolo significa executar um segundo serviço. Num servidor Linux isso é uma instância OpenVPN com a sua própria CA, certificado de servidor, certificados de cliente e diretivas server e push, além de uma regra de firewall para a sua porta. A entrada de peer WireGuard existente não descreve nenhum desses objetos. Planeie o conjunto de endereços e as rotas empurradas em separado do AllowedIPs do WireGuard, porque não são o mesmo mecanismo com dois nomes.

Depois verifique a partir do cliente: o perfil carrega, a sessão TLS conclui-se, a rota empurrada aparece e o tráfego chega a um anfitrião que só é alcançável pelo túnel.

Onde a ideia de conversor é segura

Traduzir valores à mão para notas é aceitável e muitas vezes útil, porque o endpoint, os endereços e a chave pública do peer são apenas factos sobre a implementação. Carregar uma chave privada para um site que promete conversão não é aceitável, porque essa chave é a credencial e o serviço não tem protocolo para a converter. Se precisa do mesmo acesso a partir de um cliente OpenVPN, peça uma credencial OpenVPN.

Mantenha as duas configurações lado a lado e trate-as como caminhos de acesso separados, porque é isso que são.

Artigos relacionados