SSTP falla donde el HTTPS del navegador funciona: por qué
SSTP se ejecuta dentro de TLS en el puerto 443, pero no es una petición web. Pruebe TCP, la identidad TLS, el intercambio SSTP y la autenticación PPP como etapas separadas.
El navegador abre el nombre de host de la VPN por HTTPS sin quejarse, y el cliente SSTP sigue negándose a conectarse. Nada de esa pareja es contradictorio. SSTP usa TLS como transporte exterior y luego ejecuta su propia petición y la carga PPP dentro de esa conexión, así que una carga de página correcta demuestra solo una cosa muy concreta: el host responde a un GET en el puerto 443. El cliente hace otra pregunta, y el servidor puede responderla mal.
La página carga y el túnel no
La gente recurre a la prueba del navegador porque es rápida, y luego toma el resultado como prueba de que el servidor es accesible y está configurado. Es una prueba sobre un GET a la ruta que haya abierto la barra de direcciones, nada más. La conversación VPN empieza tras el mismo handshake TLS, pero envía un método y una ruta que una página web nunca usa. Por eso una respuesta 200 para el navegador no dice nada sobre si existe el punto final SSTP.
Separe las dos observaciones y la búsqueda se acorta. El transporte y la cadena de certificados funcionan, y algo en el intercambio de protocolo por encima no funciona. Es una investigación distinta de la de un puerto roto o un certificado caducado, y necesita pruebas distintas.
Qué envía realmente el cliente SSTP
El cliente envía una petición HTTP con el método SSTP_DUPLEX_POST a la ruta /sra_{GUID}/, y luego mantiene abierto el cuerpo de la conexión como un flujo bidireccional que transporta tramas PPP. Un servidor conforme responde HTTP/1.1 200 y deja de comportarse como un servidor web. Cualquier otra cosa es una firma: 405 o 404 significa que el punto final no está, 301 o 302 significa que algo redirige la petición, y un FIN inmediato significa que un proxy o servidor cerró el flujo.
Por eso el objetivo debe ser un servidor SSTP y no un servidor web con un certificado TLS atornillado. El método, la ruta y el cuerpo de larga duración son requisitos del protocolo, así que un proxy inverso no puede añadirlos solo con configuración. Un proxy que reenvía HTTPS normal a la perfección puede rechazar un método que no reconoce.
Dónde un proxy o servidor web rompe el flujo
Un intermediario inspecciona la línea de petición HTTP antes de reenviar nada, y un método personalizado con una ruta inusual puede incumplir sus reglas. Algunos dispositivos sirven una página normal mientras rechazan o interrumpen el túnel, así que el cliente informa de una conexión que empieza y luego muere en lugar de un rechazo limpio. Otros aceptan la petición y luego aplican un tiempo de espera de cuerpo o de inactividad que los keepalives PPP no sobreviven. Ambos se ven igual desde el lado del cliente, por eso la etapa que falló importa más que el texto del error.
Compartir el puerto 443 entre un sitio web y SSTP es una decisión de enrutamiento, no una promesa de que cada salto trate las dos conversaciones igual. Si hay un balanceador de carga, un cortafuegos o un terminador TLS en la ruta, añádalo a la lista de sospechosos antes de tocar la configuración de la VPN.
Pruebe las etapas por separado
Ejecute las comprobaciones en orden y deténgase en el primer fallo, porque cada etapa descarta una capa distinta. La sonda TLS de abajo separa la identidad del certificado de todo lo que hace SSTP. Sustituya el nombre de host por su punto final y lea el asunto y la cadena que imprime.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comLuego asigne las pruebas restantes a las etapas en lugar de adivinar a partir del error del cliente. La tabla de abajo es la lista de comprobación para citar en el ticket, con la firma que separa un fallo del siguiente.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Registre en el ticket la última etapa que tuvo éxito en lugar de escribir "no se puede conectar". La especificación MS-SSTP documenta la petición y el intercambio PPP que siguen al handshake TLS, y es la referencia de por qué una prueba en el navegador no puede sustituir a ninguno de los dos.
Primero la identidad, luego PPP
La identidad TLS y la autenticación PPP son secuenciales, no alternativas, y confundirlas lleva a la gente a la configuración de servidor equivocada. El cliente valida primero el certificado del servidor y su propósito previsto, luego PPP negocia su propio estado y autentica al usuario con un método de desafío-respuesta o EAP. Un problema de certificado produce un error distinto al de una contraseña rechazada, y ninguno de los dos errores describe la etapa que cubre el otro.
Cambiar el nombre de host por una dirección, o saltarse el aviso de certificado, elimina la comprobación que habría identificado la etapa fallida en lugar de corregirla. Mantenga el aviso y léalo. Tampoco restablezca una contraseña PPP cuando el intercambio HTTP nunca llegó al comportamiento SSTP, porque la credencial nunca se pidió.