Cliente nativo do SoftEther ou perfil OpenVPN: escolha a porta certa

Um servidor SoftEther pode responder ao mesmo tempo na porta SSL nativa e numa porta compatível com OpenVPN, o que faz os dois parecerem um único serviço com duas portas. São dois serviços com clientes diferentes, formatos de configuração diferentes e capacidades diferentes. Pôr um perfil nativo num cliente OpenVPN falha na análise, e o erro raramente diz por quê.

Escolha primeiro o ouvinte, depois o cliente.

Dois ouvintes, dois formatos de configuração

O protocolo nativo usa um cliente SoftEther e uma definição de conexão que nomeia o servidor, a porta, o hub virtual e o usuário. O ouvinte compatível com OpenVPN espera um perfil OpenVPN com uma diretiva remote, material TLS e opções de um conjunto suportado muito menor do que o oferecido por um servidor OpenVPN autônomo. O SoftEther chama isso de função de clone do OpenVPN, e clone é uma pista útil sobre a fidelidade.

A compatibilidade é uma questão de versão. Verifique o que a compilação implantada aceita, não o que documenta um manual atual do OpenVPN.

Passo 1: descubra qual ouvinte o operador ativou

Peça a lista de ouvintes em vez de adivinhar a partir de um número de porta. Um servidor que responde com TLS na 443 não é necessariamente um ponto de extremidade OpenVPN, porque o protocolo nativo pode usar a mesma porta. A seção do manual sobre funções de servidor compatíveis descreve quais clones existem e como são ativados.

Se conseguir chegar ao host, teste a porta que lhe foi dada e não a porta de um tutorial: openssl s_client -connect vpn.example.com:443 -brief pelo menos diz se há TLS.

Passo 2: use o cliente e o perfil correspondentes

Para acesso nativo, instale o cliente SoftEther, crie uma conexão com os dados do operador e conecte o adaptador virtual. Para o ouvinte compatível, importe o perfil OpenVPN que o operador exportou do servidor, porque ele carrega o material de CA e de cliente que esse ouvinte espera. Não monte um perfil à mão a partir de um exemplo genérico nem cole uma definição de conexão nativa numa configuração do OpenVPN.

Um erro de análise na importação é um problema de formato, não de rede, e não deveria mandá-lo ao firewall.

Passo 3: mantenha a comparação honesta

Se o operador publicar os dois, compare-os mantendo o dispositivo, a rede de acesso e a tarefa sem mudanças. Os dois caminhos podem diferir na autenticação, nas sub-redes a que se ligam e no que o servidor faz depois com o seu tráfego. Um host compartilhado não é uma política compartilhada. Mantenha também a tarefa sem mudanças, porque copiar um arquivo e uma videochamada pressionam partes diferentes do mesmo caminho.

Resista às correções que aparecem sempre que uma importação falha. Desativar as verificações de certificados ou ativar cifras antigas para forçar um perfil é uma regressão, não uma função de compatibilidade.

Passo 4: verifique o caminho depois de conectar

Depois de conectar, verifique o endereço recebido, as rotas que vieram com ele, o DNS e um recurso interno. No lado nativo, o adaptador virtual é a interface a inspecionar; no lado OpenVPN, é o dispositivo tun ou tap criado pelo cliente. De qualquer forma, a pergunta é se o ouvinte escolhido entrega o acesso de que você precisa, o que é um fato separado de o túnel ter subido. Anote o endereço antes e depois, e compare-os.

Anote qual ouvinte e qual versão de cliente produziram o resultado que funciona. Caso contrário, a próxima pessoa repetiria a descoberta a partir do número da porta.