SSTP versus OpenVPN: același port 443, alt protocol

Ambele opțiuni pot sta în spatele TCP 443, așa că oamenii presupun că sunt puncte terminale interschimbabile. Nu sunt: SSTP server vorbește PPP în interiorul HTTPS, în timp ce un server OpenVPN vorbește propriul protocol peste TLS sau printr-un flux UDP brut. Direcționarea unui client către portul celuilalt produce o conexiune care nu ajunge niciodată la un prompt de autentificare. Alegerea privește ce client și ce transport poți susține, nu numărul.

Un port comun nu face un protocol comun

Strângerea de mână TLS se poate încheia și totuși nu duce nicăieri, pentru că apoi clientul și serverul nu sunt de acord cu ce să spună în continuare. Într-o captură de pachete vezi o strângere de mână curată urmată de date de aplicație pe care cealaltă parte le respinge sau le ignoră. Acest model este semnătura unei nepotriviri de protocol, nu a unui blocaj de firewall.

Nici un profil redenumit, nici o altă intrare de meniu nu transformă unul în celălalt. O conexiune SSTP se creează din setările VPN din Windows cu o adresă de server și datele de autentificare ale operatorului, în timp ce o conexiune OpenVPN are nevoie de client și de fișierul de configurare potrivit. Specificația SSTP a Microsoft o descrie pe prima și nu descrie o strângere de mână OpenVPN.

Portul 443 este o comoditate de politică. Trec prin rețele care permit puțin altceva, iar acesta este un avantaj real, dar nu spune nimic despre ce protocol rulează în spatele lui.

SSTP tunelează PPP în interiorul HTTPS

Numele descrie construcția: cadre PPP transportate într-o sesiune HTTPS, ceea ce înseamnă TLS dedesubt și un certificat pe care clientul îl poate verifica. Windows îl include ca tip de VPN nativ, așa că un laptop administrat se poate conecta adesea fără software suplimentar în afara profilului furnizat de operator.

Alte platforme sunt altă poveste. Un client Linux sau macOS are nevoie de o implementare întreținută, iar acestea diferă în ce suportă și cum raportează erorile. Verifică clientul pe care intenționezi să îl folosești efectiv în loc să presupui că abilitatea integrată a Windows se transferă și confirmă că numele serverului din profil corespunde certificatului prezentat de server.

SSTP este de obicei doar TCP. Acel singur transport afectează comportamentul pe o legătură cu pierderi, deoarece retransmisia are loc atât în interiorul tunelului, cât și dedesubtul lui.

OpenVPN aduce propriul client și o alegere de transport

OpenVPN furnizează propriul client și profil, ceea ce îți oferă diagnostice pe care o casetă de dialog nativă Windows nu le expune. Serverul poate asculta pe UDP sau TCP, iar configurația operatorului decide pe care trebuie să îl folosească clientul tău. Un profil îndreptat spre transportul greșit eșuează înainte de autentificare.

Autentificarea depinde la fel de mult de configurație. O implementare poate cere doar certificate, certificate plus un nume de utilizator și o parolă, sau un al doilea factor deasupra, iar clientul trebuie să corespundă exact acelei aranjamente. Faptul că o conexiune ajunge la etapa TLS nu îți spune ce acreditări va cere în continuare.

UDP este valoarea implicită obișnuită pentru că evită imbricarea unui flux fiabil într-un alt flux fiabil. Modul TCP există pentru rețelele care blochează UDP și funcționează, dar pierderile mari îl pot face să se simtă mai rău decât calea UDP pe care a înlocuit-o. Alege TCP când trebuie, nu pentru că sună mai fiabil.

Alege după client, transport și suport

Trei întrebări rezolvă majoritatea acestor decizii. Are fiecare dispozitiv client nevoie de o conexiune care funcționează fără software suplimentar? Rețeaua de care depinzi permite UDP, sau TCP 443 este singura ieșire? Și cine susține clientul, actualizările lui și recuperarea lui când un profil expiră?

Când le compari pe cele două, testează pe același dispozitiv și în aceeași rețea de acces. Dacă punctul terminal SSTP și punctul terminal OpenVPN sunt servere diferite sau locații diferite, rezultatul tău include acele rute și mașini în loc să izoleze protocolul. Acesta este cel mai obișnuit mod în care astfel de comparații dau un răspuns încrezător, dar greșit.

Apoi confirmă pe care l-ai stabilit efectiv înainte de a depana orice altceva:

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

În orice caz, încheie testând resursa și DNS-ul de care ai nevoie în loc să declari succes la starea tunelului. Ambele protocoale pot fi configurate să transporte doar trafic privat selectat, iar un tunel conectat fără rezolvare de nume funcțională arată ca un VPN stricat când de fapt este un proiect de tunel divizat sau de DNS.

Într-o flotă administrată, distribuirea profilelor și suportul pentru actualizări decid de obicei întrebarea mult înainte de orice măsurătoare de transport.