Un servidor SoftEther pode responder á vez no porto SSL nativo e nun porto compatible con OpenVPN, o que fai que os dous parezan un único servizo con dúas portas. Son dous servizos con clientes distintos, formatos de configuración distintos e capacidades distintas. Meter un perfil nativo nun cliente OpenVPN falla ao analizalo, e o erro raramente di por que.

Escolla primeiro o escoitador e despois o cliente.

Dous escoitadores, dous formatos de configuración

O protocolo nativo usa un cliente SoftEther e unha definición de conexión que nomea o servidor, o porto, o concentrador virtual e o usuario. O escoitador compatible con OpenVPN espera un perfil OpenVPN cunha directiva remote, material TLS e opcións dun conxunto admitido moito menor que o que ofrece un servidor OpenVPN independente. SoftEther chámao función de clon de OpenVPN, e clon é unha pista útil sobre a fidelidade.

A compatibilidade é unha cuestión de versión. Comprobe que acepta a compilación despregada en lugar do que documenta un manual actual de OpenVPN.

Paso 1: averigüe que escoitador habilitou o operador

Pida a lista de escoitadores en lugar de adiviñar a partir dun número de porto. Un servidor que responde con TLS no 443 non é necesariamente un extremo de OpenVPN, porque o protocolo nativo pode usar o mesmo porto. A sección do manual sobre funcións de servidor compatibles describe que clons existen e como se habilitan.

Se pode chegar ao host, probe o porto que lle deron e non o porto dun titorial: openssl s_client -connect vpn.example.com:443 -brief polo menos dille se hai TLS.

Paso 2: use o cliente e o perfil correspondentes

Para o acceso nativo, instale o cliente SoftEther, cree unha conexión cos datos do operador e conecte o adaptador virtual. Para o escoitador compatible, importe o perfil OpenVPN que o operador exportou do servidor, porque leva o material de CA e de cliente que ese escoitador espera. Non monte un perfil a man a partir dun exemplo xenérico nin pegue unha definición de conexión nativa nunha configuración de OpenVPN.

Un erro de análise ao importar é un problema de formato, non de rede, e non debería envialo ao cortafogos.

Paso 3: manteña a comparación honesta

Se o operador publica os dous, compáreos mantendo o dispositivo, a rede de acceso e a tarefa sen cambios. Os dous camiños poden diferir na autenticación, nas subredes ás que se conectan e no que o servidor fai despois co seu tráfico. Un host compartido non é unha política compartida. Manteña tamén a tarefa sen cambios, porque copiar un ficheiro e unha videollamada someten a presión partes distintas do mesmo camiño.

Resista as solucións que aparecen cada vez que falla unha importación. Desactivar as comprobacións de certificados ou habilitar cifrados antigos para forzar un perfil é unha regresión, non unha función de compatibilidade.

Paso 4: verifique o camiño despois de conectar

Unha vez conectado, comprobe o enderezo que recibiu, as rutas que viñeron con el, o DNS e un recurso interno. No lado nativo, o adaptador virtual é a interface que hai que inspeccionar; no lado de OpenVPN, é o dispositivo tun ou tap que creou o cliente. En calquera caso, a pregunta é se o escoitador que escolleu entrega o acceso que necesita, o cal é un feito aparte de se o túnel se levantou. Anote o enderezo antes e despois, e compáreos.

Anote que escoitador e que versión de cliente produciron o resultado que funciona. Se non, a seguinte persoa repetiría o descubrimento desde o número de porto.

Artigos relacionados