Cliente nativo de SoftEther ou perfil OpenVPN: escolla o porto correcto
Un servidor SoftEther pode expor á vez un escoitador nativo e un clon de OpenVPN. Necesitan clientes e perfís distintos, e poden aplicar políticas distintas.
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.