SSTP dietro un proxy che ispeziona TLS: dove si rompe la sessione

Il browser carica l’intranet aziendale, il certificato del proxy è attendibile, eppure il client SSTP cade verso la fine della connessione. Questo schema indica la differenza tra una richiesta web e una sessione in tunnel, non una password sbagliata. Percorrete la connessione da TCP in su e annotate la prima fase che fallisce. È la fase, non il codice di errore, a dirvi se il proxy è la causa.

Iniziate dove si ferma il client

Il client attraversa una sequenza fissa: connessione TCP alla porta 443, handshake TLS, validazione del certificato, lo scambio HTTP di SSTP, la negoziazione e l’autenticazione PPP, poi la configurazione IP. Un guasto a ogni fase lascia una firma diversa, e confonderli vi porta alla pagina di configurazione sbagliata.

Un guasto TCP è un timeout o un reset prima che compaia un solo byte TLS. Un guasto TLS è un avviso o un timeout dell’handshake. Un guasto del certificato produce un avviso sulla catena o sul nome. Un guasto HTTP arriva dopo un handshake riuscito, spesso come codice di stato o chiusura immediata. Un guasto PPP arriva dopo che il tunnel è tecnicamente stabilito, per questo sembra un problema di autenticazione.

Leggete il log del client per l’ultima fase riuscita invece che per la prima riga di errore. La riga di errore di solito riporta la conseguenza, mentre il confine della fase nomina il componente che ha rifiutato.

Che cosa SSTP chiede alla rete di trasportare

SSTP funziona su TLS sulla TCP 443 e poi invia una richiesta HTTP chiamata SSTP_DUPLEX_POST, definita nella specifica SSTP, verso un percorso del tipo /sra_{GUID}/. La richiesta dichiara una lunghezza del contenuto praticamente illimitata e mantiene il flusso aperto in entrambe le direzioni per tutta la durata della sessione. I frame PPP viaggiano dentro quel flusso.

Per questo un proxy che gestisce la navigazione ordinaria può comunque fallire. Una GET o una POST con corpo finito può essere bufferizzata, ispezionata e inoltrata; un flusso duplex con un corpo che non finisce mai no. Un proxy che attende il completamento del corpo attende per sempre, e il client alla fine va in timeout.

Il filtro dei metodi e l’autenticazione aggiungono i propri modi di fallire. Se il proxy chiede credenziali per la richiesta, il client VPN potrebbe non rispondere anche se il browser lo farebbe. Se rimuove o riscrive il metodo, il gateway rifiuta la richiesta prima che inizi PPP.

Perché l’ispezione cambia l’identità

Un proxy che ispeziona TLS termina la connessione TLS del client e ne apre una separata verso il gateway. Il client quindi valida il certificato del proxy, non quello del gateway, e il gateway vede il proxy come suo pari. Quando l’organizzazione distribuisce la propria radice, sia il browser sia il client VPN possono accettare quella catena, così l’handshake riesce e il problema passa alla fase successiva.

Una validazione riuscita non significa che il proxy possa trasportare la sessione. Deve ancora inoltrare una POST bidirezionale illimitata senza buffer e mantenere entrambe le connessioni vive per ore. Molti prodotti di ispezione sono costruiti per traffico richiesta-risposta e gestiscono questo caso male o per niente.

Per questo aggiungere una radice sconosciuta o disattivare la verifica è la riparazione sbagliata. Cambia quale certificato accetta il client; non fa nulla sulla gestione del flusso che ha davvero rotto la sessione.

Identificate l’emittente prima di cambiare le impostazioni

Chiedete all’endpoint quale certificato presenta e chi lo ha firmato. I comandi seguenti mostrano la catena e l’emittente senza avviare una sessione VPN:

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

Se l’emittente è una CA pubblica, la connessione probabilmente non viene intercettata per questo host e il guasto è altrove. Se l’emittente è la CA dell’organizzazione stessa, l’ispezione è attiva e il gateway si raggiunge tramite un proxy. Confrontate l’impronta con quella che il team di rete si aspetta prima di concludere solo dal nome.

Un test del browser verso lo stesso host dimostra solo che il proxy accetta una GET. Non dice nulla sul metodo SSTP, sull’URI della richiesta o sulla vita del corpo, quindi non prendete una pagina intranet funzionante come prova che il percorso del tunnel sia supportato.

Scegliete il percorso supportato

Ponete al proprietario della rete una domanda concreta: il proxy consente una POST duplex senza buffer verso questo gateway sulla porta 443? Un sì porta a un’eccezione nel proxy o a una deviazione documentata per l’host VPN. Un no significa che il percorso ispezionato non può trasportare SSTP, e la correzione supportata è un altro percorso o protocollo, non un ritocco del client.

Le opzioni di solito includono un’uscita non ispezionata per il gateway VPN, un progetto a tunnel diviso che manda solo il traffico aziendale attraverso il proxy, o un protocollo alternativo supportato dall’organizzazione su un’altra porta. Ognuna appartiene al progetto di rete e ognuna dovrebbe essere testata con lo stesso dispositivo e profilo perché il confronto isoli il percorso.

Documentate il risultato: emittente, fase fallita, regola del proxy e percorso scelto. La prossima persona che vede lo stesso blocco al 98 per cento potrà verificare un solo fatto invece di ripetere tutto il percorso.