Por que un perfil de OpenVPN non se importa en SoftEther

Dous ficheiros que ambos parecen configuración de VPN chegan ao mesmo cartafol, e só un deles funciona. O perfil de OpenVPN describe un túnel TLS con directivas que ese cliente entende, mentres que unha conexión de SoftEther describe unha sesión contra un concentrador virtual cun contrato de autenticación distinto. Converter un no outro non é un exercicio de formato, porque os dous clientes non implementan o mesmo protocolo. Identificar que servizo publicou realmente o operador decide todo o que segue.

Dous ficheiros, dous contratos

Un perfil de OpenVPN é unha configuración de cliente: un extremo remoto, un transporte, material TLS e directivas para o encamiñamento e a renegociación. Unha conexión de SoftEther é unha sesión de cliente nativo contra un concentrador virtual, cun adaptador virtual conectado a ela.

Poden describir o acceso á mesma rede sen ser intercambiables. O oínte de OpenVPN é unha función de compatibilidade que o servidor pode publicar nun porto separado, e fala OpenVPN en lugar do protocolo nativo. O cliente nativo fala o protocolo nativo e espera o seu propio perfil. Un servidor, dúas portas e cada porta ten a súa propia clave.

A extensión do ficheiro non lle di case nada, por iso a resposta do operador importa máis que o nome do ficheiro.

Lea o servidor antes de tocar un bloque de certificado

Pregunte ao operador tres cousas: que porto e transporte, que método de autenticación e que cliente esperan que use. Esas respostas eliminan a maior parte das conxecturas.

Despois confirme que está realmente á escoita e non que afirma unha guía. Un oínte de compatibilidade desactivado non mostra nada no seu porto, e un activado mostra un socket mesmo cando ninguén se conectou nunca. A diferenza entre un porto pechado e un inicio de sesión rexeitado é o primeiro diagnóstico útil. Todo o que vén despois depende de a que porta se chamou.

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

Un porto UDP que falta na lista de oíntes é unha función desactivada e non un problema de devasas.

Que necesita o cliente nativo e un perfil non lle pode dar

O cliente nativo instala un adaptador de rede virtual e vincula unha conexión a el. Sen ese adaptador non hai interface pola que encamiñar, e por iso unha conexión nativa pode autenticarse e aínda así non transportar tráfico.

A autenticación nativa execútase contra un concentrador virtual, cun obxecto de usuario que creou o administrador do concentrador. Os bloques de certificado copiados dun perfil de OpenVPN non se converten en usuarios do concentrador, e un usuario do concentrador non se converte en certificado de cliente. Os dous sistemas gardan cousas distintas, e un perfil non ten onde poñer o rexistro de usuario do concentrador. Iso é unha diferenza estrutural e non un problema de sintaxe.

Manteña a clave privada fóra de calquera servizo de conversión, porque unha clave que sae da máquina debe tratarse como revelada.

Que acepta o oínte compatible con OpenVPN

O oínte de compatibilidade é un servidor OpenVPN real desde o punto de vista do cliente: espera un cliente OpenVPN e as directivas que ese cliente admite. Os bloques de certificado en liña son unha función de OpenVPN, e pertencen a ese lado do valado.

O que non fará é aceptar un perfil nativo de SoftEther, porque ese perfil non é unha configuración de OpenVPN. O oínte tampouco converte o cliente nativo nun cliente OpenVPN. Se o operador só ofrece o servizo nativo, a resposta é o cliente nativo; se ofrece o oínte de compatibilidade, a resposta é OpenVPN e o seu propio material.

Pida a exportación compatible do operador en lugar de montar unha con fragmentos, xa que a exportación leva detalles que un ficheiro feito á man adoita pasar por alto.

Demostre o camiño antes de editar directivas

Unha vez elixido o cliente, probe o túnel antes de tocar as rutas. Un inicio de sesión correcto e unha interface que transporta tráfico son dous resultados distintos.

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 enderezo asignado co conxunto que describiu o operador e despois revise as rutas e o resolutor por separado. Unha conexión nativa ao concentrador pode autenticarse limpiamente e non instalar ningunha ruta, o que desde o lado do cliente parece un túnel roto. Só cando eses tres coinciden paga a pena editar unha directiva. Editar antes oculta que capa era a incorrecta.