Cliente nativo de SoftEther o perfil OpenVPN: elija el puerto correcto

Un servidor SoftEther puede responder a la vez en el puerto SSL nativo y en un puerto compatible con OpenVPN, lo que hace que ambos parezcan un solo servicio con dos puertas. Son dos servicios con clientes distintos, formatos de configuración distintos y capacidades distintas. Meter un perfil nativo en un cliente OpenVPN falla al analizarlo, y el error rara vez dice por qué.

Elija primero el escucha y después el cliente.

Dos escuchas, dos formatos de configuración

El protocolo nativo usa un cliente SoftEther y una definición de conexión que nombra el servidor, el puerto, el concentrador virtual y el usuario. El escucha compatible con OpenVPN espera un perfil OpenVPN con una directiva remote, material TLS y opciones de un conjunto admitido mucho menor que el que ofrece un servidor OpenVPN independiente. SoftEther lo llama función de clon de OpenVPN, y clon es una pista útil sobre la fidelidad.

La compatibilidad es una cuestión de versión. Compruebe qué acepta la compilación desplegada en lugar de qué documenta un manual actual de OpenVPN.

Paso 1: averigüe qué escucha ha habilitado el operador

Pida la lista de escuchas en lugar de adivinar a partir de un número de puerto. Un servidor que responde con TLS en el 443 no es necesariamente un extremo de OpenVPN, porque el protocolo nativo puede usar el mismo puerto. La sección del manual sobre funciones de servidor compatibles describe qué clones existen y cómo se habilitan.

Si puede llegar al host, pruebe el puerto que le dieron y no el puerto de un tutorial: openssl s_client -connect vpn.example.com:443 -brief al menos le dice si hay TLS.

Paso 2: use el cliente y el perfil correspondientes

Para el acceso nativo, instale el cliente SoftEther, cree una conexión con los datos del operador y conecte el adaptador virtual. Para el escucha compatible, importe el perfil OpenVPN que el operador exportó del servidor, porque lleva el material de CA y de cliente que ese escucha espera. No arme un perfil a mano a partir de un ejemplo genérico ni pegue una definición de conexión nativa en una configuración de OpenVPN.

Un error de análisis al importar es un problema de formato, no de red, y no debería mandarlo al cortafuegos.

Paso 3: mantenga la comparación honesta

Si el operador publica ambos, compárelos manteniendo el dispositivo, la red de acceso y la tarea sin cambios. Los dos caminos pueden diferir en la autenticación, en las subredes a las que se conectan y en lo que el servidor hace después con su tráfico. Un host compartido no es una política compartida. Mantenga también la tarea sin cambios, porque copiar un archivo y una videollamada someten a presión partes distintas del mismo camino.

Resista las soluciones que aparecen cada vez que falla una importación. Desactivar las comprobaciones de certificados o habilitar cifrados antiguos para forzar un perfil es una regresión, no una función de compatibilidad.

Paso 4: verifique el camino después de conectar

Una vez conectado, compruebe la dirección que recibió, las rutas que vinieron con ella, el DNS y un recurso interno. En el lado nativo, el adaptador virtual es la interfaz que hay que inspeccionar; en el lado de OpenVPN, es el dispositivo tun o tap que creó el cliente. En cualquier caso, la pregunta es si el escucha que eligió entrega el acceso que necesita, lo cual es un hecho aparte de si el túnel se levantó. Anote la dirección antes y después, y compárelas.

Anote qué escucha y qué versión de cliente produjeron el resultado que funciona. De lo contrario, la siguiente persona repetiría el descubrimiento desde el número de puerto.