Timeout SSTP o errore di certificato: come distinguerli

Una connessione SSTP fallisce in due modi che dalla sedia dell’utente sembrano uguali, e la riparazione di ciascuno sta su un livello diverso. Un timeout significa che uno scambio necessario non si è mai concluso; un errore di certificato significa che il materiale d’identità è arrivato ed è stato rifiutato. Trattare il secondo come il primo porta verso firewall e password che non sono mai stati il problema. La prova che li distingue sta nel registro del client stesso, se lo si legge prima di cambiare qualsiasi cosa.

Due guasti, due scambi diversi

SSTP trasporta un tunnel dentro una sessione a forma di HTTPS, per questo sopravvive alle reti che non consentono altro che la 443. Il client completa un handshake TLS, invia una richiesta HTTP con un metodo specifico del protocollo, poi il tunnel scorre dentro quel flusso. Un guasto in uno di questi passaggi ferma la connessione, e solo i successivi coinvolgono le credenziali.

Quest’ordine è la diagnosi. Se l’handshake TLS non si completa mai, nessuna credenziale è stata inviata, quindi reimpostare la password non può aiutare. Se l’handshake si completa e poi si blocca, l’identità è stata accettata e qualcosa nel percorso della richiesta l’ha rifiutata. Se l’handshake fallisce con un messaggio di validazione, il server ha risposto e al client non è piaciuto ciò che ha sentito. Tre esiti, tre livelli.

La riga di registro di solito indica in quale dei tre ci si trova, per questo vale la pena catturarla prima del primo cambiamento.

Un timeout significa che una fase non si è mai conclusa

Inizia dalla risoluzione dei nomi e dalla raggiungibilità TCP, perché un timeout lì sembra identico a un timeout più avanti. Un controllo di porta che riporta la 443 aperta dimostra solo che un listener ha accettato una connessione, e nulla oltre.

Il sospetto successivo è il percorso e non l’host. I proxy e i firewall consapevoli delle applicazioni a volte rifiutano il metodo di richiesta usato da SSTP, o scartano un flusso che resta aperto per ore, e entrambi i comportamenti sembrano un timeout dal lato del client. Una pagina HTTPS generica servita dallo stesso host si carica perfettamente mentre il metodo del tunnel viene rifiutato, per questo navigare verso l’endpoint dimostra così poco. Prova da una rete senza il proxy per separare i due casi.

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Un timeout prima di qualsiasi risposta della controparte non dice nulla sull’account, e cambiare la password in quel momento aggiunge solo una variabile.

Un errore di certificato significa che l’identità è stata rifiutata

Qui il server ha risposto davvero, quindi la rete funziona e la domanda passa all’identità. Confronta il nome con cui il client compone con i nomi che il certificato afferma davvero, poi controlla le date di validità e la catena emittente.

Una CA privata di cui il client non si fida produce la stessa classe di errore di un certificato scaduto, e così pure un orologio sfasato di ore. Comporre l’indirizzo grezzo crea una nuova discordanza, perché un certificato afferma nomi e non indirizzi. In una distribuzione gestita, ottieni la configurazione di fiducia prevista dal suo amministratore invece di accettare una radice sostitutiva offerta da una pagina di errore. La validazione resta attiva mentre correggi la causa.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Mantieni intatta la fase TLS riuscita una volta superata, perché annullarla più tardi nasconde quale modifica abbia davvero riparato il tunnel.

Dove i due si confondono

Entrambi i guasti si presentano come una connessione che non sale, ed entrambi arrivano dopo che l’utente ha cambiato qualcosa di non correlato. È quella coincidenza a rendere plausibile la riparazione sbagliata per un po’.

Due abitudini li tengono separati. Cattura il registro del client prima di toccare la configurazione, così il primo stato resta conservato. Cambia un livello per tentativo, così il risultato successivo appartiene a una variabile nota. Un controllo di porta e un browser sono osservazioni parziali e non la sequenza completa, e nessuno dei due sostituisce il rapporto del client stesso. Nessuna delle due abitudini costa nulla, ed entrambe accorciano l’indagine.

La questione del certificato e quella della raggiungibilità sono documentate separatamente per una ragione.

Riprova con il client reale, poi avanza verso l’interno

Una volta applicata la correzione specifica, riprova con il client SSTP reale e il profilo vero, non con una scheda del browser.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

Se la sessione si connette e le risorse continuano a fallire, il tunnel non è più il sospetto: passa a routing, DNS e accesso ai servizi. È un’altra indagine con altre prove. Conservare le fasi TLS e di autenticazione che funzionano impedisce che diventi una ripetizione della prima. Scrivi nel ticket la fase che ha fallito, altrimenti la persona successiva ripartirà dall’alto.