¿Qué protocolos ofrece realmente este nodo VPN público?

El software lo admite, por tanto el nodo lo ofrece. Esa inferencia es errónea con la suficiente frecuencia como para ser una regla: un despliegue de SoftEther puede activar cualquier subconjunto de sus métodos de conexión compatibles, y un nodo público es un despliegue con un propietario y una configuración. Con qué puedes conectarte depende de ese nodo, no de la lista de funciones del proyecto que ejecuta. La brecha entre ambos es donde viven en realidad la mayoría de los tiques de «el protocolo está roto».

Qué promete en realidad la lista del proyecto

Las funciones de protocolo del proyecto describen de qué es capaz el servidor. Un nodo determinado activa algunos de esos escuchadores y no otros, y el operador puede cambiar ese conjunto sin tocar la versión del software. Por eso dos nodos de la misma compilación se comportan de forma distinta, y un perfil que funciona contra uno no demuestra nada sobre el siguiente objetivo. La lista del propio nodo pesa más que la página del proyecto cuando eliges dónde conectarte.

Lee la lista como cinco campos, no como un menú: punto de conexión, puerto, transporte, familia de protocolos y método de autenticación. Un nodo público que anuncia SSTP te ha hablado de un escuchador en un puerto; no te ha dicho qué certificado presenta ni si tu cuenta funciona allí. Comparar esos cinco campos con tu perfil es más rápido que cualquier cantidad de reinstalación del cliente, y produce una expectativa escrita que puedes probar más adelante.

Ajusta el perfil al punto de conexión que nombra

Una entrada nativa de SoftEther no es automáticamente una configuración de OpenVPN, incluso cuando ambas aparecen en una página de proveedor bajo un mismo encabezado. Cuando un nodo publica tanto un escuchador TCP como uno UDP para OpenVPN, trátalos como dos puntos de conexión: un perfil editado de uno al otro apunta a un escuchador que nadie activó. La etiqueta de transporte del archivo forma parte de la dirección, no es un ajuste cosmético.

Que el cliente acepte un archivo importado demuestra que el archivo se analiza. No dice nada sobre si un escuchador remoto espera al otro lado, y por eso el primer intento de conexión es la prueba real. Compara la línea remota del perfil con el host y el puerto anunciados del nodo antes de culpar al protocolo.

Sondea la etapa que falla

Un host que responde al tráfico web todavía puede carecer del servicio VPN previsto, y un host que rechaza un protocolo no está necesariamente caído para todos. Esos dos errores envían a la gente en direcciones opuestas la misma tarde. Uno persigue un cortafuegos que está bien; el otro reinstala un cliente que nunca fue el problema. Sondea cada ruta por separado para que la respuesta describa un escuchador y no todo el host.

Estas cinco comprobaciones cubren los métodos habituales de los nodos públicos. Ejecútalas desde la misma red que usa el cliente, porque un puerto filtrado parece idéntico a un escuchador ausente desde lejos.

nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example

Asigna cada error observado a su fila antes de cambiar nada. Un fallo de identidad TLS demuestra que el escuchador existe, así que reescribir el perfil hacia otro protocolo descartaría una prueba que funciona. Una conexión rechazada solo demuestra que este puerto no respondió, lo que es una afirmación mucho más estrecha que «el nodo no admite OpenVPN».

Conserva el error antes de cambiar nada

Anota el resultado exacto: un tiempo agotado, un fallo de identidad del certificado, un rechazo de la cuenta y una denegación a nivel de aplicación son cuatro desenlaces distintos. Solo el primero trata de un protocolo no disponible, y solo el último trata de permisos tras una conexión correcta. Reiniciar el cliente o cambiar de protocolo destruye esa distinción, porque el siguiente fallo llega con otro historial y sin línea base con la que comparar.

No debilites la verificación para que un perfil incompatible parezca funcionar. Una comprobación de certificado desactivada convierte un fallo de identidad claro en una conexión a algo que no pretendías alcanzar, y el éxito resultante es peor que el error original porque oculta qué etapa estaba mal.

Vuelve a comprobar por cada nodo, cada vez

Las opciones nativas SSL, OpenVPN, L2TP/IPsec y SSTP de una lista de nodo público describen la configuración de ese nodo en ese momento. El mismo software en otro lugar puede presentar un conjunto distinto, y un proveedor puede retirar un escuchador entre tu marcador y tu siguiente intento. Las notas antiguas describen despliegues antiguos.

Anota el perfil verificado con su punto de conexión y método, y luego repite la sonda cuando el nodo cambie o la conexión empiece a fallar. La especificación del protocolo SoftEther es la referencia de lo que el software puede hacer; la lista del propio nodo es la referencia de lo que hace. Mantén los dos documentos separados y el diagnóstico se vuelve más corto.