Por qué un perfil de OpenVPN no se importa en SoftEther

Dos archivos que parecen configuración de VPN llegan a la misma carpeta y solo uno de ellos funciona. El perfil de OpenVPN describe un túnel TLS con directivas que ese cliente entiende, mientras que una conexión de SoftEther describe una sesión contra un concentrador virtual con un contrato de autenticación distinto. Convertir uno en otro no es un ejercicio de formato, porque los dos clientes no implementan el mismo protocolo. Identificar qué servicio publicó realmente el operador decide todo lo que sigue.

Dos archivos, dos contratos

Un perfil de OpenVPN es una configuración de cliente: un extremo remoto, un transporte, material TLS y directivas para el enrutamiento y la renegociación. Una conexión de SoftEther es una sesión de cliente nativo contra un concentrador virtual, con un adaptador virtual conectado a ella.

Pueden describir el acceso a la misma red sin ser intercambiables. El oyente de OpenVPN es una función de compatibilidad que el servidor puede publicar en un puerto aparte, y habla OpenVPN en lugar del protocolo nativo. El cliente nativo habla el protocolo nativo y espera su propio perfil. Un servidor, dos puertas y cada puerta tiene su propia clave.

La extensión del archivo no le dice casi nada, por eso la respuesta del operador importa más que el nombre del archivo.

Lea el servidor antes de tocar un bloque de certificado

Pregunte al operador tres cosas: qué puerto y transporte, qué método de autenticación y qué cliente esperan que use. Esas respuestas eliminan casi todas las conjeturas.

Luego confirme qué está realmente a la escucha y no qué afirma una guía. Un oyente de compatibilidad desactivado no muestra nada en su puerto, y uno activado muestra un socket incluso cuando nadie se ha conectado nunca. La diferencia entre un puerto cerrado y un inicio de sesión rechazado es el primer diagnóstico útil. Todo lo que viene después depende de a qué puerta se llamó.

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 puerto UDP que falta en la lista de oyentes es una función desactivada y no un problema de cortafuegos.

Qué necesita el cliente nativo y un perfil no puede darle

El cliente nativo instala un adaptador de red virtual y vincula una conexión a él. Sin ese adaptador no hay interfaz por la que enrutar, y por eso una conexión nativa puede autenticarse y aun así no transportar tráfico.

La autenticación nativa se ejecuta contra un concentrador virtual, con un objeto de usuario que creó el administrador del concentrador. Los bloques de certificado copiados de un perfil de OpenVPN no se convierten en usuarios del concentrador, y un usuario del concentrador no se convierte en certificado de cliente. Los dos sistemas guardan cosas distintas, y un perfil no tiene dónde poner el registro de usuario del concentrador. Eso es una diferencia estructural y no un problema de sintaxis.

Mantenga la clave privada fuera de cualquier servicio de conversión, porque una clave que sale de la máquina debe tratarse como revelada.

Qué acepta el oyente compatible con OpenVPN

El oyente de compatibilidad es un servidor OpenVPN real desde el punto de vista del cliente: espera un cliente OpenVPN y las directivas que ese cliente admite. Los bloques de certificado en línea son una función de OpenVPN y pertenecen a ese lado de la valla.

Lo que no hará es aceptar un perfil nativo de SoftEther, porque ese perfil no es una configuración de OpenVPN. El oyente tampoco convierte al cliente nativo en un cliente OpenVPN. Si el operador ofrece solo el servicio nativo, la respuesta es el cliente nativo; si ofrece el oyente de compatibilidad, la respuesta es OpenVPN y su propio material.

Pida la exportación compatible del operador en lugar de montar una con fragmentos, ya que la exportación lleva detalles que un archivo hecho a mano suele pasar por alto.

Demuestre la ruta antes de editar directivas

Una vez elegido el cliente, pruebe el túnel antes de tocar las rutas. Un inicio de sesión correcto y una interfaz que transporta tráfico son dos 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 la dirección asignada con el grupo que describió el operador y luego revise las rutas y el resolutor por separado. Una conexión nativa al concentrador puede autenticarse limpiamente y no instalar ninguna ruta, lo que desde el lado del cliente parece un túnel roto. Solo cuando esos tres coinciden vale la pena editar una directiva. Editar antes oculta qué capa era la incorrecta.