SSTP è PPP su HTTPS, non una pagina web sulla porta 443

SSTP trasporta PPP dentro una connessione HTTPS, ed è per questo che sembra traffico web a qualunque cosa stia nel mezzo. TLS e HTTP stabiliscono il canale esterno, poi i messaggi di controllo SSTP preparano il tunnel e PPP fornisce il comportamento della sessione. Un browser che carica una pagina allo stesso indirizzo ha completato solo una parte della prima fase. Considerarlo un test VPN è il modo in cui un proxy che funziona viene incolpato di una discrepanza di protocollo.

Percorri le quattro fasi in ordine, e il guasto che vedi cadrà in una di esse.

Fase 1: TCP e TLS

Il client apre una connessione TCP verso la porta 443 ed esegue un handshake TLS. La catena di certificati deve corrispondere al nome host con cui è stato configurato il client. Una discrepanza di nome qui produce un guasto prima che venga scambiato qualsiasi messaggio SSTP, e la specifica SSTP dà per scontato che questo canale HTTPS esterno esista già. Nulla nelle fasi successive può compensare un guasto di fiducia qui.

Un comune server web può completare questa fase perfettamente e fallire comunque nella successiva. Il successo di TLS è una prova sul certificato, non sul protocollo che sta dietro.

Fase 2: la richiesta HTTPS

SSTP effettua la sua richiesta con un metodo specifico, SSTP_DUPLEX_POST, e mantiene lo scambio aperto invece di restituire un documento. Un server o proxy configurato per richieste di pagina ordinarie può accettare la connessione e poi rifiutare il metodo. Quel rifiuto è il problema di compatibilità che le persone di solito descrivono come porta 443 bloccata.

Leggi il codice di risposta e il metodo nel log del server. Un rifiuto in questa fase è un problema diverso da un timeout TCP, e i due portano a correzioni diverse.

Fase 3: i messaggi di controllo

Una volta accettata la richiesta, SSTP scambia messaggi di controllo che negoziano e preparano il tunnel. Sono messaggi di protocollo dentro il corpo HTTPS, non richieste HTTP, quindi un proxy che ispeziona e riscrive i corpi può romperli lasciando intatte le richieste di pagina.

Qui un apparato di ispezione profonda si guadagna la reputazione. Se le pagine si caricano e la VPN fallisce, controlla se il corpo viene modificato invece di controllare se la porta è aperta.

Fase 4: PPP prende il controllo

PPP fornisce poi il comportamento della sessione: negoziazione del collegamento, autenticazione e la configurazione del livello di rete che segue. L’autenticazione PPP è separata dal controllo TLS che il client ha già superato. Un certificato del server che il client accetta non dice nulla sulla validità delle credenziali dell’utente o sull’autorizzazione dell’account.

Un certificato accettato e un accesso rifiutato non sono contraddittori. Sono fasi consecutive con esiti indipendenti.

L’autenticazione ha diversi ruoli

Il client convalida l’identità del server TLS rispetto al proprio archivio di fiducia e al nome configurato. Poi PPP autentica l’utente o la macchina, a seconda della distribuzione. Il server può aggiungere una propria politica su chi può connettersi e a cosa può arrivare. Mantieni il nome host coerente con l’identità del certificato, perché sostituirlo con un indirizzo grezzo trasforma una configurazione funzionante in un guasto di verifica del nome.

Annota quale fase ha segnalato il guasto. Certificato, metodo, messaggio di controllo, autenticazione PPP, poi route: cinque punti, cinque riparazioni.

Cosa può e cosa non può mostrare un test nel browser

Caricare una pagina all’indirizzo dimostra la risoluzione DNS, la raggiungibilità TCP e che qualcosa è in ascolto e parla HTTP. Non dimostra che il metodo sia accettato, che lo scambio di controllo sopravviva o che l’autenticazione PPP sia configurata. Usa un client che implementa SSTP invece di convertire un altro profilo cambiando la porta.

Una volta attiva la sessione, route, DNS e inoltro lato server decidono ancora a cosa può arrivare l’utente. Il tunnel è un percorso, non un’autorizzazione.