SSTP contro OpenVPN: stessa porta 443, protocollo diverso

Entrambe le opzioni possono stare dietro TCP 443, così le persone presumono che siano endpoint intercambiabili. Non lo sono: SSTP server parla PPP dentro HTTPS, mentre un server OpenVPN parla il proprio protocollo su TLS o tramite un flusso UDP grezzo. Puntare un client alla porta dell’altro produce una connessione che non arriva mai a un prompt di accesso. La scelta riguarda quale client e quale trasporto puoi supportare, non il numero.

Una porta condivisa non fa un protocollo condiviso

L’handshake TLS può completarsi e comunque non portare da nessuna parte, perché poi il client e il server non concordano su cosa dire dopo. In una cattura di pacchetti vedi un handshake pulito seguito da dati applicativi che la controparte rifiuta o ignora. Quel pattern è la firma di una discrepanza di protocollo, non di un blocco del firewall.

Né un profilo rinominato né una voce di menu diversa converte l’uno nell’altro. Una connessione SSTP si crea dalle impostazioni VPN di Windows con un indirizzo del server e i dati di autenticazione dell’operatore, mentre una connessione OpenVPN richiede il client e il file di configurazione corrispondente. La specifica SSTP di Microsoft descrive la prima e non descrive un handshake OpenVPN.

La porta 443 è una comodità di policy. Passa attraverso reti che consentono poco altro, e questo è un vantaggio reale, ma non ti dice nulla su quale protocollo viaggia dietro.

SSTP incapsula PPP dentro HTTPS

Il nome descrive la costruzione: frame PPP trasportati dentro una sessione HTTPS, cioè TLS sotto e un certificato che il client può controllare. Windows lo include come tipo di VPN nativo, così un portatile gestito spesso può connettersi senza software aggiuntivo oltre al profilo fornito dall’operatore.

Le altre piattaforme sono un’altra storia. Un client Linux o macOS richiede un’implementazione mantenuta, e queste variano in ciò che supportano e in come segnalano gli errori. Controlla il client che intendi realmente usare invece di presumere che la capacità integrata di Windows si trasferisca, e conferma che il nome del server nel profilo corrisponda al certificato presentato dal server.

SSTP è di solito solo TCP. Quel singolo trasporto influenza il comportamento su un collegamento con perdite, perché la ritrasmissione avviene dentro il tunnel e anche sotto.

OpenVPN porta il proprio client e una scelta di trasporto

OpenVPN fornisce il proprio client e profilo, il che ti dà diagnostica che una finestra di dialogo nativa di Windows non espone. Il server può ascoltare su UDP o TCP, e la configurazione dell’operatore decide quale deve usare il tuo client. Un profilo puntato al trasporto sbagliato fallisce prima dell’autenticazione.

L’autenticazione dipende altrettanto dalla configurazione. Un deployment può richiedere solo certificati, certificati più nome utente e password, o un secondo fattore in aggiunta, e il client deve corrispondere esattamente a quella disposizione. Il fatto che una connessione raggiunga la fase TLS non ti dice quali credenziali chiederà dopo.

UDP è il valore predefinito abituale perché evita di annidare un flusso affidabile dentro un altro flusso affidabile. La modalità TCP esiste per le reti che bloccano UDP, e funziona, ma perdite pesanti possono farla sembrare peggiore del percorso UDP che ha sostituito. Scegli TCP quando devi, non perché suona più affidabile.

Scegli per client, trasporto e supporto

Tre domande risolvono la maggior parte di queste decisioni. Ogni dispositivo client ha bisogno di una connessione che funzioni senza software aggiuntivo? La rete da cui dipendi consente UDP, o TCP 443 è l’unica uscita? E chi supporta il client, i suoi aggiornamenti e il suo ripristino quando un profilo scade?

Quando confronti i due, prova sullo stesso dispositivo e sulla stessa rete di accesso. Se l’endpoint SSTP e l’endpoint OpenVPN sono server diversi o siti diversi, il tuo risultato include quelle rotte e quelle macchine invece di isolare il protocollo. È il modo più comune in cui questi confronti producono una risposta sicura ma sbagliata.

Poi conferma quale hai effettivamente stabilito prima di eseguire il debug di qualsiasi altra cosa:

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

In ogni caso, chiudi testando la risorsa e il DNS che ti servono invece di dichiarare successo allo stato del tunnel. Entrambi i protocolli possono essere configurati per trasportare solo traffico privato selezionato, e un tunnel connesso senza risoluzione dei nomi funzionante sembra una VPN rotta quando in realtà è un progetto di tunnel diviso o di DNS.

In una flotta gestita, la distribuzione dei profili e il supporto agli aggiornamenti decidono di solito la questione molto prima di qualsiasi benchmark di trasporto.