La porta 443 risponde, SSTP fallisce ancora: quale fase si è rotta?

Completare un handshake TCP verso la porta 443 mentre il tunnel non si costruisce mai dimostra una cosa, ed è una cosa piccola. Qualcosa è in ascolto e disposto ad accettare una connessione a quell’indirizzo. Non identifica il servizio, il certificato che presenterà né cosa accade dopo i primi byte.

Quattro fasi separano quell’handshake da un tunnel funzionante, e ciascuna produce un errore diverso.

Una porta aperta descrive un solo livello

Accettare una connessione TCP significa che un processo possiede il socket e che il percorso consente l’handshake. Non dice nulla sul fatto che quel processo sia un server SSTP, che abbia un certificato valido per il nome nel vostro profilo o che autorizzi il vostro account. Un server web allo stesso indirizzo risponde perfettamente all’handshake e poi risponde alla vostra richiesta SSTP con un errore HTTP. Tutto ciò che sta sopra quell’handshake resta non testato.

Trattate il test della porta come il filtro più economico possibile e non come un verdetto. Il suo valore è che elimina un’intera categoria di guasti, non che confermi tutto ciò che sta sopra.

Confondere le due cose è il motivo per cui le persone reinstallano i client dopo un test che non ha mai esaminato il vero problema del client.

Separate le quattro fasi con le prove

Le fasi sono la raggiungibilità del trasporto, la validazione TLS, lo scambio SSTP su HTTPS e l’autenticazione PPP dentro il tunnel. Un percorso che supera la prima e fallisce la quarta richiede una correzione delle credenziali; uno che fallisce la seconda richiede una correzione di certificato o di nome. Queste riparazioni non hanno nulla in comune, e scegliere quella sbagliata spreca l’interruzione.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

Il terzo comando merita una lettura attenta. Un 200 da una normale pagina web vi dice che c’è un servizio web; non vi dice che la richiesta SSTP sarà compresa. Un 404 dallo stesso indirizzo è altrettanto poco informativo sul VPN. Solo il registro del client vi dice quale delle quattro fasi è stata raggiunta.

Notate quale nome ha usato ciascun comando. Il certificato viene scelto in base al nome che inviate, quindi una discrepanza tra il profilo e il test è una discrepanza che avete introdotto voi. Scrivere quel nome accanto al risultato evita la confusione in seguito.

Leggete il successo parziale nella direzione giusta

Un intermediario può consentire la navigazione ordinaria e rifiutare lo scambio successivo, ed è per questo che un proxy che funziona per i siti web può ancora fallire per un tunnel. Lo stesso schema appare quando un certificato è valido per un nome di browser ma non per il nome configurato nel profilo: il browser è soddisfatto e il client no, ed entrambi hanno ragione su ciò che hanno controllato.

Mantenete attiva la validazione del server mentre diagnosticate questo. Disattivarla trasforma una discrepanza di certificato in un handshake riuscito e nasconde l’unica prova che avrebbe spiegato il guasto.

Se lo stesso profilo funziona da un’altra rete, la differenza dipende dal percorso. Questo restringe la ricerca agli intermediari senza dire quale, ed è comunque un passo utile avanti. Registrate la rete che avete usato, perché il confronto è inutile senza di essa.

Poi provate l’applicazione, non solo la sessione

Una volta che esiste una sessione, verificate la rotta prevista, la risoluzione dei nomi e il permesso di servizio dal client che ne ha bisogno. Un tunnel connesso può ancora avere un inoltro mancante sul lato remoto o una rotta di ritorno che non è mai esistita, e quei guasti sembrano esattamente un problema dell’applicazione alla persona che aspetta.

Mantenete ogni conclusione legata alla fase che l’ha prodotta. Chiamare una porta aperta un VPN funzionante è il modo in cui un controllo del certificato di cinque minuti diventa una giornata di reinstallazione del software.