Come verificare se un client VPN supporta davvero SSTP

Definire un prodotto client VPN non dice nulla sul fatto che parli SSTP, e la porta 443 nell'indirizzo dimostra ancora meno. SSTP esegue TLS su TCP 443, poi uno scambio di controllo SSTP, poi PPP per il collegamento stesso, con la validazione del certificato e un metodo di autenticazione PPP sopra. Un client supporta il protocollo solo quando l'implementazione indicata, nella versione installata, completa ognuno di questi livelli secondo i requisiti del vostro server. Eseguite i controlli qui sotto in ordine e fermatevi al primo che fallisce, perché è quello che vale la pena risolvere.

Allineate implementazione, versione e piattaforma

Iniziate dalla piattaforma, dall'applicazione e dalla build installata, perché un solo nome di fornitore può stare su due implementazioni completamente diverse. I tipi VPN integrati e i client di terze parti non sono la stessa cosa, e un plug-in può mostrare un'etichetta di adattatore che non descrive il protocollo sottostante. La documentazione della versione corrente non descrive la build in esecuzione sulla macchina davanti a voi. Leggete la pagina specifica della versione, poi confrontatela con ciò che il client dichiara di sé.

In Windows il tipo di tunnel proviene dalla piattaforma e non dall'interfaccia grafica, quindi chiedete alla piattaforma. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress mostra Sstp quando il client nativo tenterà il protocollo, e il riferimento sui tipi di connessione lo elenca tra i tipi di tunnel integrati. In Linux non esiste alcun client SSTP nativo, quindi la domanda diventa se un'implementazione separata come sstpc del pacchetto sstp-client sia installata e aggiornata.

Leggete il formato del profilo prima dell'etichetta

I profili non sono intercambiabili, e il file che vi è stato consegnato di solito risolve la questione più in fretta di qualsiasi elenco di funzioni. Le direttive OpenVPN, le chiavi WireGuard e le impostazioni di connessione SSTP descrivono tre protocolli senza rapporto, e nessuna finestra di importazione trasforma l'uno nell'altro. Condividere la porta TCP 443 non traduce nulla, perché SSTP, OpenVPN su TLS e un normale servizio HTTPS possono occupare la stessa porta e non avere nulla in comune al di sopra.

Se il file è un .ovpn o una configurazione WireGuard, la risposta è già chiara: a quel client non viene chiesto di parlare SSTP. Importarlo in un client che fa solo SSTP fallisce già nella fase del profilo, molto prima che inizi qualsiasi negoziazione del protocollo.

Cosa TLS non dimostra sul deployment

Un handshake TLS completato dimostra che il server possiede un certificato, e non dimostra nulla sul fatto che il vostro client si fidi della catena emittente o che il nome al suo interno corrisponda. La validazione deve riuscire verso il server previsto, compresa qualsiasi CA privata gestita dall'organizzazione, e un client che offre di saltare gli errori di certificato ha rimosso il controllo invece di aver ottenuto il supporto del protocollo. La validazione della catena e la corrispondenza del nome sono due test distinti, e uno stack che supera l'uno può fallire sull'altro. Entrambi appartengono ai criteri di accettazione, non all'appendice di risoluzione dei problemi.

Poi confermate il metodo di autenticazione PPP, perché un deployment con EAP-TLS richiede un client in grado di presentare un certificato all'interno di PPP, mentre un metodo basato su password richiede il supporto per quello scambio. Un indirizzo del server e una password non descrivono il requisito reale dell'organizzazione, soprattutto quando davanti c'è un secondo fattore o un controllo del dispositivo. Chiedete quale metodo impone il server prima di presumere che il client possa soddisfarlo.

Seguite la sessione attraverso quattro fasi

Osservate la connessione attraversare quattro confini: TCP e TLS verso il server, lo scambio di controllo SSTP, la negoziazione PPP, poi la risorsa che vi serve davvero. Un registro che si ferma dopo TLS descrive un guasto diverso da uno che si ferma dentro PPP, e i due portano a responsabili diversi. Il caricamento della pagina web dell'host da parte di un browser dimostra solo che qualcosa ha risposto sulla 443, che è il falso positivo più comune in questo campo. Se quella pagina si carica mentre il client continua a fallire, il problema sta sopra TLS e il server web non è il sospetto.

Concludete con una risorsa privata reale e una risoluzione del nome, perché una sessione che si stabilisce e non trasporta nulla appare identica a una funzionante nella maggior parte delle finestre di stato. Una sola richiesta riuscita alla risorsa che vi serve risolve una questione che l'icona non può.

Quando il supporto manca, cambiate piano

Se il client non può parlare SSTP, procuratevi un'alternativa approvata o chiedete al proprietario del server un protocollo supportato da entrambe le estremità. Eliminare le opzioni non riconosciute finché un'importazione riesce produce un profilo che non si connette a nulla, che è una strada più lenta verso lo stesso vicolo cieco. Un programma di installazione da fonte sconosciuta che pubblicizza una compatibilità universale aggiunge un percorso di fiducia non approvato alla macchina e spesso sostituisce il client della piattaforma con qualcosa che l'organizzazione non può aggiornare. Nessuna delle due mosse è una correzione, ed entrambe sono più difficili da annullare del problema originale.

Trattate la questione della compatibilità separatamente dalle prestazioni e dalla scelta dell'endpoint, perché un server vicino è inutile quando il client non può parlare il suo protocollo. La messa a punto della latenza non ripara una fase che non si completa mai.