SSTP kontraŭ OpenVPN: sama pordo 443, malsama protokolo

Ambaŭ elektoj povas stari malantaŭ TCP 443, do homoj supozas, ke ili estas interŝanĝeblaj finpunktoj. Ili ne estas: SSTP servilo parolas PPP ene de HTTPS, dum OpenVPN-servilo parolas sian propran protokolon super TLS aŭ tra kruda UDP-fluo. Direkti unu klienton al la pordo de la alia produktas konekton, kiu neniam atingas ensalutan prompton. La elekto temas pri kiun klienton kaj transporton vi povas subteni, ne pri la numero.

Komuna pordo ne faras komunan protokolon

La TLS-manpremo povas finiĝi kaj tamen konduki nenien, ĉar poste la kliento kaj la servilo malkonsentas pri tio, kion diri sekve. En paketa kaptaĵo vi vidas puran manpremon sekvatan de aplikaj datumoj, kiujn la alia flanko malakceptas aŭ ignoras. Tiu ŝablono estas la signo de protokola malkongruo, ne de blokado per fajroŝirmilo.

Nek alinomita profilo nek alia menuero konvertas unu en la alian. SSTP-konekto kreiĝas el la Windows VPN-agordoj kun servila adreso kaj la aŭtentigaj detaloj de la operatoro, dum OpenVPN-konekto bezonas la klienton kaj la konforman agordan dosieron. La SSTP-specifo de Microsoft priskribas la unuan, kaj ĝi ne priskribas OpenVPN-manpremon.

Pordo 443 estas politika oportuneco. Ĝi trapasas retojn, kiuj permesas malmulte alian, kaj tio estas reala avantaĝo, sed ĝi diras nenion pri tio, kiu protokolo funkcias malantaŭ ĝi.

SSTP tuneligas PPP ene de HTTPS

La nomo priskribas la konstruon: PPP-kadroj portataj ene de HTTPS-sesio, kio signifas TLS sube kaj atestilon, kiun la kliento povas kontroli. Windows inkluzivas ĝin kiel indiĝenan VPN-specon, do administrata tekkomputilo ofte povas konektiĝi sen plia programaro krom la profilo, kiun la operatoro liveras.

Aliaj platformoj estas alia historio. Linux- aŭ macOS-kliento bezonas prizorgatan implementaĵon, kaj tiuj varias en tio, kion ili subtenas kaj kiel ili raportas erarojn. Kontrolu la klienton, kiun vi fakte intencas uzi, anstataŭ supozi, ke la enkonstruita Windows-kapablo transiĝas, kaj konfirmu, ke la servila nomo en la profilo kongruas kun la atestilo, kiun la servilo prezentas.

SSTP estas kutime nur TCP. Tiu unu transporto influas, kiel ĝi kondutas sur ligo kun perdoj, ĉar retranssendado okazas ene de la tunelo kaj ankaŭ sube.

OpenVPN alportas sian propran klienton kaj elekton de transporto

OpenVPN liveras sian propran klienton kaj profilon, kio donas al vi diagnozon, kiun indiĝena Windows-dialogaĵo ne montras. La servilo povas aŭskulti sur UDP aŭ TCP, kaj la agordo de la operatoro decidas, kiun via kliento devas uzi. Profilo direktita al la malĝusta transporto malsukcesas antaŭ aŭtentigo.

Aŭtentigo same dependas de agordo. Unuo povas postuli nur atestilojn, atestilojn plus uzantnomon kaj pasvorton, aŭ duan faktoron supre, kaj la kliento devas kongrui ĝuste al tiu aranĝo. La fakto, ke konekto atingas la TLS-etapon, ne diras, kiujn legitimilojn ĝi petos sekve.

UDP estas la kutima defaŭlto, ĉar ĝi evitas nesti fidindan fluon en alia fidinda fluo. La TCP-reĝimo ekzistas por retoj, kiuj blokas UDP, kaj ĝi funkcias, sed granda perdo povas igi ĝin sentiĝi pli malbone ol la UDP-vojo, kiun ĝi anstataŭigis. Elektu TCP kiam vi devas, ne ĉar ĝi sonas pli fidinda.

Elektu laŭ kliento, transporto kaj subteno

Tri demandoj solvas la plej multajn el tiuj decidoj. Ĉu ĉiu klienta aparato bezonas konekton, kiu funkcias sen plia programaro? Ĉu la reto, de kiu vi dependas, permesas UDP, aŭ ĉu TCP 443 estas la sola eliro? Kaj kiu subtenas la klienton, ĝiajn ĝisdatigojn kaj ĝian restaŭron, kiam profilo eksvalidiĝas?

Kiam vi komparas la du, testu sur la sama aparato kaj la sama alira reto. Se la SSTP-finpunkto kaj la OpenVPN-finpunkto estas malsamaj serviloj aŭ malsamaj lokoj, via rezulto inkluzivas tiujn vojojn kaj maŝinojn anstataŭ izoli la protokolon. Tio estas la plej ofta maniero, per kiu tiaj komparoj donas memfidan sed malĝustan respondon.

Poste konfirmu, kiun vi efektive starigis, antaŭ ol senerarigi ion ajn alian:

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

Ĉiuokaze, finu per testado de la rimedo kaj la DNS, kiujn vi bezonas, anstataŭ deklari sukceson ĉe la tunela stato. Ambaŭ protokoloj povas esti agorditaj por porti nur elektitan privatan trafikon, kaj konektita tunelo sen funkcianta nomrezolvo aspektas kiel rompita VPN, kiam ĝi fakte estas dividita tunela aŭ DNS-aranĝo.

En administrata aro, profil-disdonado kaj ĝisdatiga subteno kutime decidas la demandon longe antaŭ iu ajn transporta mezuro.