Por que um perfil OpenVPN não é importado no SoftEther

Dois arquivos que ambos parecem uma configuração de VPN chegam à mesma pasta, e só um deles funciona. O perfil OpenVPN descreve um túnel TLS com diretivas que aquele cliente entende, enquanto uma conexão SoftEther descreve uma sessão contra um concentrador virtual com um contrato de autenticação diferente. Converter um no outro não é um exercício de formatação, porque os dois clientes não implementam o mesmo protocolo. Identificar qual serviço o operador realmente publicou decide tudo o que se segue.

Dois arquivos, dois contratos

Um perfil OpenVPN é uma configuração de cliente: um endpoint remoto, um transporte, material TLS e diretivas para roteamento e renegociação. Uma conexão SoftEther é uma sessão de cliente nativo contra um concentrador virtual, com um adaptador virtual conectado a ela.

Eles podem descrever o acesso à mesma rede sem serem intercambiáveis. O listener OpenVPN é um recurso de compatibilidade que o servidor pode publicar numa porta separada, e ele fala OpenVPN em vez do protocolo nativo. O cliente nativo fala o protocolo nativo e espera o seu próprio perfil. Um servidor, duas portas, e cada porta tem a sua própria chave.

A extensão do arquivo quase não lhe diz nada, por isso a resposta do operador importa mais que o nome do arquivo.

Leia o servidor antes de tocar num bloco de certificado

Pergunte ao operador três coisas: qual porta e transporte, qual método de autenticação e qual cliente esperam que você use. Essas respostas eliminam a maior parte das suposições.

Depois confirme o que está realmente à escuta, e não o que um guia afirma. Um listener de compatibilidade desativado não mostra nada na sua porta, e um ativado mostra um socket mesmo quando ninguém nunca se conectou. A diferença entre uma porta fechada e um login recusado é o primeiro diagnóstico útil. Tudo o que vem depois depende de a qual porta se bateu.

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

Uma porta UDP ausente da lista de listeners é um recurso desativado e não um problema de firewall.

O que o cliente nativo precisa e um perfil não pode dar

O cliente nativo instala um adaptador de rede virtual e vincula uma conexão a ele. Sem esse adaptador não há interface por onde rotear, e por isso uma conexão nativa pode autenticar-se e ainda assim não transportar tráfego.

A autenticação nativa corre contra um concentrador virtual, com um objeto de utilizador criado pelo administrador do concentrador. Blocos de certificado copiados de um perfil OpenVPN não se tornam utilizadores do concentrador, e um utilizador do concentrador não se torna um certificado de cliente. Os dois sistemas guardam coisas diferentes, e um perfil não tem onde colocar o registo de utilizador do concentrador. Isso é uma diferença estrutural e não um problema de sintaxe.

Mantenha a chave privada fora de qualquer serviço de conversão, porque uma chave que sai da máquina tem de ser tratada como revelada.

O que o listener compatível com OpenVPN aceita

O listener de compatibilidade é um servidor OpenVPN real do ponto de vista do cliente: espera um cliente OpenVPN e as diretivas que esse cliente suporta. Os blocos de certificado inline são um recurso do OpenVPN, e pertencem àquele lado da cerca.

O que ele não fará é aceitar um perfil nativo do SoftEther, porque esse perfil não é uma configuração OpenVPN. O listener também não transforma o cliente nativo num cliente OpenVPN. Se o operador oferece apenas o serviço nativo, a resposta é o cliente nativo; se oferece o listener de compatibilidade, a resposta é OpenVPN e o seu próprio material.

Peça a exportação suportada do operador em vez de montar uma a partir de fragmentos, porque a exportação transporta detalhes que um arquivo feito à mão costuma omitir.

Prove o caminho antes de editar diretivas

Escolhido o cliente, teste o túnel antes de tocar nas rotas. Um login bem-sucedido e uma interface que transporta tráfego são dois resultados diferentes.

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

Compare o endereço atribuído com o conjunto que o operador descreveu, e depois olhe para as rotas e o resolver em separado. Uma conexão nativa ao concentrador pode autenticar-se de forma limpa e não instalar nenhuma rota, o que do lado do cliente parece um túnel quebrado. Só quando esses três coincidem vale a pena editar uma diretiva. Editar antes esconde qual camada estava errada.