Cómo comprobar si un cliente VPN admite SSTP de verdad

Llamar cliente VPN a un producto no dice nada sobre si habla SSTP, y el puerto 443 en la dirección demuestra aún menos. SSTP ejecuta TLS sobre TCP 443, luego un intercambio de control SSTP, luego PPP para el propio enlace, con validación de certificado y un método de autenticación PPP por encima. Un cliente admite el protocolo solo cuando la implementación citada, en la versión instalada, completa cada una de esas capas frente a los requisitos de su servidor. Haga las comprobaciones siguientes en orden y deténgase en la primera que falle, porque es la que merece resolverse.

Haga coincidir la implementación, la versión y la plataforma

Empiece por la plataforma, la aplicación y la compilación instalada, porque un nombre de fabricante puede cubrir dos implementaciones completamente distintas. Los tipos de VPN integrados y los clientes de terceros no son lo mismo, y un complemento puede mostrar una etiqueta de adaptador que no describe el protocolo que hay debajo. La documentación de la versión actual no describe la compilación que se ejecuta en la máquina que tiene delante. Lea la página específica de la versión y compárela con lo que el cliente declara sobre sí mismo.

En Windows el tipo de túnel proviene de la plataforma y no de la interfaz gráfica, así que pregunte a la plataforma. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress muestra Sstp cuando el cliente nativo intentará el protocolo, y la referencia de tipos de conexión lo incluye entre los tipos de túnel integrados. En Linux no existe ningún cliente SSTP nativo, así que la pregunta pasa a ser si una implementación aparte como sstpc del paquete sstp-client está instalada y al día.

Lea el formato del perfil antes de la etiqueta

Los perfiles no son intercambiables, y el archivo que le han entregado suele resolver la cuestión más rápido que cualquier lista de funciones. Las directivas de OpenVPN, las claves de WireGuard y los ajustes de conexión SSTP describen tres protocolos sin relación, y ningún diálogo de importación convierte uno en otro. Compartir el puerto TCP 443 no traduce nada, porque SSTP, OpenVPN sobre TLS y un servicio HTTPS corriente pueden ocupar el mismo puerto y no tener nada en común por encima.

Si el archivo es un .ovpn o una configuración de WireGuard, la respuesta ya está clara: a ese cliente no se le pide hablar SSTP. Importarlo en un cliente que solo hace SSTP falla en la etapa del perfil, mucho antes de que empiece cualquier negociación del protocolo.

Lo que TLS no demuestra sobre el despliegue

Un handshake TLS completado demuestra que el servidor tiene un certificado, y no demuestra nada sobre si su cliente confía en la cadena emisora o hace coincidir el nombre que contiene. La validación tiene que tener éxito contra el servidor previsto, incluida cualquier CA privada que opere la organización, y un cliente que ofrece saltarse los errores de certificado ha eliminado la comprobación en lugar de haber ganado compatibilidad con el protocolo. La validación de la cadena y la coincidencia del nombre son dos pruebas separadas, y una pila que supera una puede fallar en la otra. Ambas pertenecen a los criterios de aceptación, no al anexo de resolución de problemas.

Después confirme el método de autenticación PPP, porque un despliegue con EAP-TLS necesita un cliente que pueda presentar un certificado dentro de PPP, mientras que un método basado en contraseña necesita soporte para ese intercambio. Una dirección de servidor y una contraseña no describen el requisito real de la organización, sobre todo cuando hay un segundo factor o una comprobación del dispositivo delante. Pregunte qué método impone el servidor antes de suponer que el cliente puede satisfacerlo.

Siga la sesión por cuatro etapas

Observe cómo la conexión cruza cuatro fronteras: TCP y TLS hacia el servidor, el intercambio de control SSTP, la negociación PPP y luego el recurso que realmente necesita. Un registro que se detiene tras TLS describe un fallo distinto de uno que se detiene dentro de PPP, y ambos llevan a responsables diferentes. Que un navegador cargue la página web del host solo demuestra que algo respondió en el 443, que es el falso positivo más habitual en este ámbito. Si esa página carga mientras el cliente sigue fallando, el problema está por encima de TLS y el servidor web no es el sospechoso.

Termine con un recurso privado real y una consulta de nombre, porque una sesión que se establece y no transporta nada se ve igual que una funcional en la mayoría de las ventanas de estado. Una petición correcta al recurso que necesita resuelve una pregunta que el icono no puede.

Cuando falta compatibilidad, cambie el plan

Si el cliente no puede hablar SSTP, consiga una alternativa aprobada o pida al propietario del servidor un protocolo que ambos extremos admitan. Borrar las opciones no reconocidas hasta que una importación funcione produce un perfil que no conecta con nada, que es una ruta más lenta hacia el mismo callejón sin salida. Un instalador de origen desconocido que anuncia compatibilidad universal añade una vía de confianza no aprobada a la máquina y a menudo sustituye el cliente de la plataforma por algo que la organización no puede actualizar. Ninguna de las dos maniobras es una solución, y ambas son más difíciles de deshacer que el problema original.

Trate la cuestión de la compatibilidad por separado del rendimiento y de la elección del punto final, porque un servidor cercano no sirve de nada cuando el cliente no puede hablar su protocolo. Ajustar la latencia no repara una etapa que nunca se completa.