SSTP fallisce dove l'HTTPS del browser riesce: perché
SSTP gira dentro TLS sulla porta 443, ma non è una richiesta web. Verifica TCP, identità TLS, lo scambio SSTP e l'autenticazione PPP come fasi separate.
Il browser apre il nome host della VPN via HTTPS senza protestare, e il client SSTP continua a rifiutarsi di connettersi. Nulla in questa coppia è contraddittorio. SSTP usa TLS come trasporto esterno e poi esegue la propria richiesta e il carico PPP dentro quella connessione, quindi una pagina caricata correttamente dimostra solo una cosa molto stretta: l'host risponde a un GET sulla porta 443. Il client pone un'altra domanda, e il server potrebbe rispondere male.
La pagina carica e il tunnel no
Le persone ricorrono al test del browser perché è veloce, e poi prendono il risultato come prova che il server è raggiungibile e configurato. È una prova su un GET al percorso aperto dalla barra degli indirizzi, niente di più. La conversazione VPN inizia dopo lo stesso handshake TLS, ma invia un metodo e un percorso che una pagina web non usa mai. Quindi una risposta 200 per il browser non dice nulla sull'esistenza dell'endpoint SSTP.
Separa le due osservazioni e la ricerca si accorcia. Trasporto e catena di certificati funzionano, e qualcosa nello scambio di protocollo sopra di essi non funziona. È un'indagine diversa da quella di una porta rotta o di un certificato scaduto, e richiede prove diverse.
Che cosa invia davvero il client SSTP
Il client invia una richiesta HTTP con il metodo SSTP_DUPLEX_POST al percorso /sra_{GUID}/, poi mantiene aperto il corpo della connessione come flusso bidirezionale che trasporta frame PPP. Un server conforme risponde HTTP/1.1 200 e smette di comportarsi come un server web. Qualsiasi altra cosa è una firma: 405 o 404 significa che l'endpoint non c'è, 301 o 302 significa che qualcosa reindirizza la richiesta, e un FIN immediato significa che un proxy o un server ha chiuso il flusso.
Per questo l'obiettivo deve essere un server SSTP e non un server web con un certificato TLS avvitato sopra. Il metodo, il percorso e il corpo di lunga durata sono requisiti del protocollo, quindi un proxy inverso non può aggiungerli con la sola configurazione. Un proxy che inoltra perfettamente HTTPS normale può comunque rifiutare un metodo che non riconosce.
Dove un proxy o un server web spezza il flusso
Un intermediario ispeziona la riga di richiesta HTTP prima di inoltrare qualsiasi cosa, e un metodo personalizzato con un percorso insolito può fallire le sue regole. Alcuni dispositivi servono una pagina normale mentre rifiutano o interrompono il tunnel, così il client segnala una connessione che parte e poi muore invece di un rifiuto pulito. Altri accettano la richiesta e poi applicano un timeout di corpo o di inattività che i keepalive PPP non sopravvivono. Entrambi sembrano uguali dal lato client, per questo la fase che ha fallito conta più del testo dell'errore.
Condividere la porta 443 tra un sito web e SSTP è una scelta di routing, non una promessa che ogni salto tratti le due conversazioni allo stesso modo. Se sul percorso c'è un bilanciatore di carico, un firewall o un terminatore TLS, aggiungilo alla lista dei sospetti prima di toccare la configurazione VPN.
Verifica le fasi separatamente
Esegui i controlli in ordine e fermati al primo fallimento, perché ogni fase esclude uno strato diverso. La sonda TLS qui sotto separa l'identità del certificato da tutto ciò che fa SSTP. Sostituisci il nome host con il tuo endpoint e leggi il subject e la catena che stampa.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comPoi mappa le prove rimanenti sulle fasi invece di indovinare dall'errore del client. La tabella qui sotto è la lista di controllo da citare nel ticket, con la firma che separa un fallimento dal successivo.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Registra nel ticket l'ultima fase riuscita invece di scrivere "impossibile connettersi". La specifica MS-SSTP documenta la richiesta e lo scambio PPP che seguono l'handshake TLS, ed è il riferimento per cui un test nel browser non può sostituire né l'una né l'altro.
Prima l'identità, poi PPP
L'identità TLS e l'autenticazione PPP sono sequenziali, non alternative, e confonderle manda le persone verso l'impostazione sbagliata del server. Il client valida prima il certificato del server e il suo scopo previsto, poi PPP negozia il proprio stato e autentica l'utente con un metodo challenge-response o EAP. Un problema di certificato produce un errore diverso da una password rifiutata, e nessuno dei due errori descrive la fase coperta dall'altro.
Sostituire il nome host con un indirizzo, o cliccare oltre l'avviso di certificato, elimina il controllo che avrebbe identificato la fase fallita invece di correggerla. Mantieni l'avviso e leggilo. Non reimpostare nemmeno una password PPP quando lo scambio HTTP non ha mai raggiunto il comportamento SSTP, perché la credenziale non è mai stata richiesta.