SSTP darrere d’un proxy que inspecciona TLS: on es trenca la sessió

El vostre navegador carrega la intranet corporativa, el certificat del proxy és de confiança, i tot i així el client SSTP cau prop del final de la connexió. Aquest patró apunta a la diferència entre una petició web i una sessió en túnel, no a una contrasenya incorrecta. Recorreu la connexió des de TCP cap amunt i anoteu la primera etapa que falla. L’etapa, no el codi d’error, us diu si el proxy n’és la causa.

Comenceu on s’atura el client

El client passa per una seqüència fixa: connexió TCP al port 443, handshake TLS, validació del certificat, l’intercanvi HTTP de SSTP, la negociació i autenticació PPP, i després la configuració IP. Una fallada a cada etapa deixa una empremta diferent, i barrejar-les us porta a la pàgina de configuració equivocada.

Una fallada TCP és un temps d’espera o un reset abans que aparegui cap byte TLS. Una fallada TLS és una alerta o un temps d’espera de handshake. Una fallada de certificat produeix un avís sobre la cadena o el nom. Una fallada HTTP arriba després d’un handshake correcte, sovint com a codi d’estat o tancament immediat. Una fallada PPP arriba després que el túnel estigui tècnicament establert, i per això sembla un problema d’autenticació.

Llegiu el registre del client per trobar l’última etapa correcta, no la primera línia d’error. La línia d’error normalment és el client informant de la conseqüència, mentre que la frontera de l’etapa nomena el component que ha refusat.

Què demana SSTP que la xarxa transporti

SSTP funciona sobre TLS al TCP 443 i després envia una petició HTTP anomenada SSTP_DUPLEX_POST, definida a l’especificació d’SSTP, a un camí de la forma /sra_{GUID}/. La petició declara una longitud de contingut efectivament il·limitada i manté el flux obert en tots dos sentits durant tota la sessió. Les trames PPP viatgen dins d’aquest flux.

Per això un proxy que gestiona la navegació ordinària encara pot fallar. Un GET o un POST amb un cos finit es pot emmagatzemar, inspeccionar i reenviar; un flux dúplex amb un cos que no acaba mai, no. Un proxy que espera que el cos es completi espera per sempre, i el client acaba esgotant el temps.

El filtratge de mètodes i l’autenticació afegeixen els seus propis modes de fallada. Si el proxy demana credencials per a la petició, el client VPN pot no respondre-hi encara que el navegador sí que ho faria. Si elimina o reescriu el mètode, la passarel·la rebutja la petició abans que comenci PPP.

Per què la inspecció canvia la identitat

Un proxy que inspecciona TLS acaba la connexió TLS del client i n’obre una de separada cap a la passarel·la. Per tant, el client valida el certificat del proxy, no el de la passarel·la, i la passarel·la veu el proxy com el seu parell. Quan l’organització distribueix la seva pròpia arrel, el navegador i el client VPN poden acceptar tots dos aquesta cadena, així que el handshake té èxit i el problema passa a l’etapa següent.

Una validació correcta no vol dir que el proxy pugui transportar la sessió. Encara ha de reenviar un POST bidireccional il·limitat sense emmagatzemar-lo i ha de mantenir les dues connexions vives durant hores. Molts productes d’inspecció estan fets per a trànsit de petició-resposta i tracten aquest cas malament o no el tracten.

També per això afegir una arrel desconeguda o desactivar la verificació és la reparació equivocada. Canvia quin certificat accepta el client; no fa res pel que fa al tractament del flux que realment va trencar la sessió.

Identifiqueu l’emissor abans de canviar paràmetres

Pregunteu al punt final quin certificat presenta i qui l’ha signat. Les ordres següents mostren la cadena i l’emissor sense iniciar cap sessió VPN:

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

Si l’emissor és una CA pública, probablement la connexió no s’intercepta per a aquest amfitrió i la fallada és en un altre lloc. Si l’emissor és la CA pròpia de l’organització, la inspecció és activa i s’arriba a la passarel·la a través d’un proxy. Compareu l’empremta amb la que espera l’equip de xarxa abans de treure conclusions només pel nom.

Una prova del navegador contra el mateix amfitrió només demostra que el proxy accepta un GET. No diu res sobre el mètode SSTP, l’URI de la petició ni la vida del cos, així que no prengueu una pàgina d’intranet que funciona com a prova que el camí del túnel és compatible.

Trieu el camí compatible

Pregunteu al propietari de la xarxa una qüestió concreta: el proxy permet un POST dúplex sense emmagatzematge cap a aquesta passarel·la al port 443? Un sí porta a una excepció del proxy o a un desviament documentat per a l’amfitrió VPN. Un no vol dir que el camí inspeccionat no pot transportar SSTP, i la solució compatible és un altre camí o protocol, no un retoc del client.

Les opcions solen incloure una sortida no inspeccionada per a la passarel·la VPN, un disseny de túnel dividit que només envia el trànsit corporatiu pel proxy, o un protocol alternatiu que l’organització admet en un altre port. Cadascuna pertany al disseny de xarxa i cadascuna s’ha de provar amb el mateix dispositiu i perfil perquè la comparació aïlli el camí.

Documenteu el resultat: emissor, etapa fallida, regla del proxy i camí triat. La propera persona que veurà la mateixa aturada al 98 per cent podrà comprovar un sol fet en lloc de repetir tot el recorregut.