SSTP detrás de un proxy que inspecciona TLS: dónde se rompe la sesión

Su navegador carga la intranet corporativa, el certificado del proxy es de confianza y, aun así, el cliente SSTP se cae cerca del final de la conexión. Ese patrón apunta a la diferencia entre una petición web y una sesión en túnel, no a una contraseña incorrecta. Recorra la conexión desde TCP hacia arriba y anote la primera etapa que falla. La etapa, no el código de error, le dice si el proxy es la causa.

Empiece donde se detiene el cliente

El cliente pasa por una secuencia fija: conexión TCP al puerto 443, handshake TLS, validación del certificado, el intercambio HTTP de SSTP, la negociación y autenticación PPP y, después, la configuración IP. Un fallo en cada etapa deja una firma distinta, y confundirlas le lleva a la página de configuración equivocada.

Un fallo TCP es un tiempo de espera o un reinicio antes de que aparezca cualquier byte TLS. Un fallo TLS es una alerta o un tiempo de espera de handshake. Un fallo de certificado produce una advertencia sobre la cadena o el nombre. Un fallo HTTP llega tras un handshake correcto, a menudo como código de estado o cierre inmediato. Un fallo PPP llega después de que el túnel esté técnicamente establecido, por eso parece un problema de autenticación.

Lea el registro del cliente para encontrar la última etapa correcta, no la primera línea de error. La línea de error suele ser el cliente informando de la consecuencia, mientras que el límite de la etapa nombra el componente que rechazó.

Qué pide SSTP que transporte la red

SSTP funciona sobre TLS en TCP 443 y luego envía una petición HTTP llamada SSTP_DUPLEX_POST, definida en la especificación de SSTP, a una ruta de la forma /sra_{GUID}/. La petición declara una longitud de contenido efectivamente ilimitada y mantiene el flujo abierto en ambos sentidos durante toda la sesión. Las tramas PPP viajan dentro de ese flujo.

Por eso un proxy que gestiona la navegación normal todavía puede fallar. Un GET o un POST con un cuerpo finito se puede almacenar, inspeccionar y reenviar; un flujo dúplex con un cuerpo que no termina nunca, no. Un proxy que espera a que el cuerpo se complete espera para siempre, y el cliente acaba agotando el tiempo.

El filtrado de métodos y la autenticación añaden sus propios modos de fallo. Si el proxy pide credenciales para la petición, el cliente VPN puede no responder aunque el navegador sí lo haría. Si elimina o reescribe el método, la pasarela rechaza la petición antes de que empiece PPP.

Por qué la inspección cambia la identidad

Un proxy que inspecciona TLS termina la conexión TLS del cliente y abre una conexión separada hacia la pasarela. Por tanto, el cliente valida el certificado del proxy, no el de la pasarela, y la pasarela ve al proxy como su par. Cuando la organización distribuye su propia raíz, tanto el navegador como el cliente VPN pueden aceptar esa cadena, así que el handshake tiene éxito y el problema pasa a la siguiente etapa.

Una validación correcta no significa que el proxy pueda transportar la sesión. Todavía tiene que reenviar un POST bidireccional ilimitado sin almacenamiento y mantener ambas conexiones vivas durante horas. Muchos productos de inspección están hechos para tráfico de petición-respuesta y tratan este caso mal o no lo tratan.

También por eso añadir una raíz desconocida o desactivar la verificación es la reparación equivocada. Cambia qué certificado acepta el cliente; no hace nada sobre el tratamiento del flujo que realmente rompió la sesión.

Identifique al emisor antes de cambiar ajustes

Pregunte al extremo qué certificado presenta y quién lo firmó. Los comandos siguientes muestran la cadena y el emisor sin iniciar una sesión VPN:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Si el emisor es una CA pública, probablemente la conexión no se intercepta para este host y el fallo está en otro sitio. Si el emisor es la CA propia de la organización, la inspección está activa y se llega a la pasarela a través de un proxy. Compare la huella con la que espera el equipo de red antes de sacar conclusiones solo por el nombre.

Una prueba del navegador contra el mismo host solo demuestra que el proxy acepta un GET. No dice nada sobre el método SSTP, la URI de la petición ni la vida del cuerpo, así que no tome una página de intranet que funciona como prueba de que la ruta del túnel es compatible.

Elija la ruta compatible

Pregunte al propietario de la red una cuestión concreta: ¿el proxy permite un POST dúplex sin almacenamiento hacia esta pasarela en el puerto 443? Un sí lleva a una excepción del proxy o a un desvío documentado para el host VPN. Un no significa que la ruta inspeccionada no puede transportar SSTP, y la solución compatible es otra ruta o protocolo, no un retoque del cliente.

Las opciones suelen incluir una salida no inspeccionada para la pasarela VPN, un diseño de túnel dividido que solo envía el tráfico corporativo por el proxy, o un protocolo alternativo que la organización admite en otro puerto. Cada una pertenece al diseño de red y cada una debe probarse con el mismo dispositivo y perfil para que la comparación aísle la ruta.

Documente el resultado: emisor, etapa fallida, regla del proxy y ruta elegida. La siguiente persona que vea el mismo bloqueo al 98 por ciento podrá comprobar un solo dato en lugar de repetir todo el recorrido.