El puerto 443 responde, SSTP sigue fallando: ¿qué etapa se rompió?

Completar un handshake TCP al puerto 443 mientras el túnel nunca se construye demuestra una cosa, y es una cosa pequeña. Algo está escuchando y dispuesto a aceptar una conexión en esa dirección. No identifica el servicio, el certificado que presentará ni qué ocurre después de los primeros bytes.

Cuatro etapas separan ese handshake de un túnel funcional, y cada una produce un error distinto.

Un puerto abierto describe solo una capa

Aceptar una conexión TCP significa que un proceso posee el socket y que la ruta permite el handshake. No dice nada sobre si ese proceso es un servidor SSTP, si tiene un certificado válido para el nombre de su perfil o si autorizará su cuenta. Un servidor web en la misma dirección responde perfectamente al handshake y luego responde a su solicitud SSTP con un error HTTP. Todo lo que está por encima de ese handshake queda sin probar.

Trate la prueba del puerto como el filtro más barato posible y no como un veredicto. Su valor es que elimina una categoría entera de fallos, no que confirme todo lo que está por encima.

Confundir ambas cosas es la razón por la que la gente reinstala clientes tras una prueba que nunca examinó el problema real del cliente.

Separe las cuatro etapas con pruebas

Las etapas son la accesibilidad del transporte, la validación TLS, el intercambio SSTP sobre HTTPS y la autenticación PPP dentro del túnel. Una ruta que supera la primera y falla en la cuarta necesita una corrección de credenciales; una que falla en la segunda necesita una corrección de certificado o de nombre. Esas reparaciones no tienen nada en común, y elegir la equivocada desperdicia la interrupción.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

El tercer comando merece leerse con atención. Un 200 de una página web corriente le dice que hay un servicio web; no le dice que la solicitud SSTP vaya a entenderse. Un 404 de la misma dirección es igual de poco informativo sobre la VPN. Solo el registro del cliente le dice a cuál de las cuatro etapas llegó.

Fíjese en qué nombre usó cada comando. El certificado se selecciona por el nombre que usted envía, así que una discrepancia entre el perfil y la prueba es una discrepancia que usted introdujo. Escribir ese nombre junto al resultado evita la confusión más adelante.

Lea el éxito parcial en la dirección correcta

Un intermediario puede permitir la navegación corriente y rechazar el intercambio posterior, y por eso un proxy que funciona para sitios web todavía puede fallar para un túnel. El mismo patrón aparece cuando un certificado es válido para un nombre de navegador pero no para el nombre configurado en el perfil: el navegador queda satisfecho y el cliente no, y ambos tienen razón sobre lo que comprobaron.

Mantenga activada la validación del servidor mientras diagnostica esto. Desactivarla convierte una discrepancia de certificado en un handshake exitoso y oculta la única prueba que habría explicado el fallo.

Si el mismo perfil funciona desde otra red, la diferencia depende de la ruta. Eso reduce la búsqueda a intermediarios sin decir cuál, y sigue siendo un paso útil hacia adelante. Registre la red que utilizó, porque la comparación no vale nada sin ella.

Luego pruebe la aplicación, no solo la sesión

Una vez que existe una sesión, verifique la ruta prevista, la resolución de nombres y el permiso de servicio desde el cliente que los necesita. Un túnel conectado todavía puede tener un reenvío ausente en el lado remoto o una ruta de retorno que nunca existió, y esos fallos parecen exactamente un problema de aplicación para la persona que espera.

Mantenga cada conclusión ligada a la etapa que la produjo. Llamar puerto abierto a una VPN funcional es cómo una comprobación de certificado de cinco minutos se convierte en un día de reinstalar software.