SSTP detrás dun proxy que inspecciona TLS: onde se rompe a sesión

O seu navegador carga a intranet corporativa, o certificado do proxy é de confianza e, aínda así, o cliente SSTP cae preto do final da conexión. Ese patrón apunta á diferenza entre unha petición web e unha sesión en túnel, non a un contrasinal incorrecto. Percorra a conexión desde TCP cara arriba e anote a primeira etapa que falla. A etapa, non o código de erro, dille se o proxy é a causa.

Comece onde se detén o cliente

O cliente pasa por unha secuencia fixa: conexión TCP ao porto 443, handshake TLS, validación do certificado, o intercambio HTTP de SSTP, a negociación e autenticación PPP e, despois, a configuración IP. Un fallo en cada etapa deixa unha sinatura distinta, e confundilas lévao á páxina de configuración equivocada.

Un fallo TCP é un tempo de espera ou un reinicio antes de que apareza calquera byte TLS. Un fallo TLS é unha alerta ou un tempo de espera de handshake. Un fallo de certificado produce un aviso sobre a cadea ou o nome. Un fallo HTTP chega tras un handshake correcto, a miúdo como código de estado ou peche inmediato. Un fallo PPP chega despois de que o túnel estea tecnicamente establecido, por iso parece un problema de autenticación.

Lea o rexistro do cliente para atopar a última etapa correcta, non a primeira liña de erro. A liña de erro adoita ser o cliente informando da consecuencia, mentres que o límite da etapa nomea o compoñente que rexeitou.

Que pide SSTP que transporte a rede

SSTP funciona sobre TLS en TCP 443 e logo envía unha petición HTTP chamada SSTP_DUPLEX_POST, definida na especificación de SSTP, a unha ruta da forma /sra_{GUID}/. A petición declara unha lonxitude de contido efectivamente ilimitada e mantén o fluxo aberto en ambos os sentidos durante toda a sesión. As tramas PPP viaxan dentro dese fluxo.

Por iso un proxy que xestiona a navegación normal aínda pode fallar. Un GET ou un POST cun corpo finito pódese almacenar, inspeccionar e reenviar; un fluxo dúplex cun corpo que nunca remata, non. Un proxy que espera a que o corpo se complete espera para sempre, e o cliente acaba esgotando o tempo.

O filtrado de métodos e a autenticación engaden os seus propios modos de fallo. Se o proxy pide credenciais para a petición, o cliente VPN pode non responder aínda que o navegador si o faría. Se elimina ou reescribe o método, a pasarela rexeita a petición antes de que comece PPP.

Por que a inspección cambia a identidade

Un proxy que inspecciona TLS termina a conexión TLS do cliente e abre unha conexión separada cara á pasarela. Por tanto, o cliente valida o certificado do proxy, non o da pasarela, e a pasarela ve o proxy como o seu par. Cando a organización distribúe a súa propia raíz, tanto o navegador como o cliente VPN poden aceptar esa cadea, así que o handshake ten éxito e o problema pasa á seguinte etapa.

Unha validación correcta non significa que o proxy poida transportar a sesión. Aínda ten que reenviar un POST bidireccional ilimitado sen almacenamento e manter ambas as conexións vivas durante horas. Moitos produtos de inspección están feitos para tráfico de petición-resposta e tratan este caso mal ou non o tratan.

Tamén por iso engadir unha raíz descoñecida ou desactivar a verificación é a reparación equivocada. Cambia que certificado acepta o cliente; non fai nada sobre o tratamento do fluxo que realmente rompeu a sesión.

Identifique o emisor antes de cambiar axustes

Pregunte ao extremo que certificado presenta e quen o asinou. Os comandos seguintes mostran a cadea e o emisor sen iniciar unha sesión VPN:

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

Se o emisor é unha CA pública, probablemente a conexión non se intercepta para este host e o fallo está noutro sitio. Se o emisor é a CA propia da organización, a inspección está activa e chégase á pasarela a través dun proxy. Compare a pegada coa que espera o equipo de rede antes de sacar conclusións só polo nome.

Unha proba do navegador contra o mesmo host só demostra que o proxy acepta un GET. Non di nada sobre o método SSTP, a URI da petición nin a vida do corpo, así que non tome unha páxina de intranet que funciona como proba de que a ruta do túnel é compatible.

Escolla a ruta compatible

Pregunte ao propietario da rede unha cuestión concreta: o proxy permite un POST dúplex sen almacenamento cara a esta pasarela no porto 443? Un si leva a unha excepción do proxy ou a un desvío documentado para o host VPN. Un non significa que a ruta inspeccionada non pode transportar SSTP, e a solución compatible é outra ruta ou protocolo, non un retoque do cliente.

As opcións adoitan incluír unha saída non inspeccionada para a pasarela VPN, un deseño de túnel dividido que só envía o tráfico corporativo polo proxy, ou un protocolo alternativo que a organización admite noutro porto. Cada unha pertence ao deseño de rede e cada unha debe probarse co mesmo dispositivo e perfil para que a comparación illa a ruta.

Documente o resultado: emisor, etapa fallida, regra do proxy e ruta elixida. A seguinte persoa que vexa o mesmo bloqueo ao 98 por cento poderá comprobar un só dato en lugar de repetir todo o percorrido.