SSTP laban sa OpenVPN: parehong port 443, ibang protocol

Ang dalawang opsyon ay maaaring nasa likod ng TCP 443, kaya inaakala ng mga tao na sila ay mapagpapalit na dulong punto. Hindi: SSTP server ay nagsasalita ng PPP sa loob ng HTTPS, habang ang isang OpenVPN server ay nagsasalita ng sarili nitong protocol sa ibabaw ng TLS o sa pamamagitan ng hilaw na daloy ng UDP. Ang pagturo ng isang kliyente sa port ng isa ay gumagawa ng koneksyon na hindi kailanman umabot sa prompt ng pag-login. Ang pagpili ay tungkol sa kung aling kliyente at transport ang maaari mong suportahan, hindi sa numero.

Ang pinagsamang port ay hindi gumagawa ng pinagsamang protocol

Ang TLS handshake ay maaaring matapos at gayon pa man ay walang patutunguhan, dahil pagkatapos ay hindi nagkakasundo ang kliyente at server sa susunod na sasabihin. Sa isang packet capture makikita mo ang malinis na handshake na sinusundan ng data ng application na tinatanggihan o binabalewala ng kabilang panig. Ang pattern na iyon ay lagda ng hindi pagtutugma ng protocol, hindi ng pagharang ng firewall.

Ni ang pinalitan ng pangalan na profile ni ang ibang entry sa menu ay hindi ginagawang isa ang isa. Ang koneksyon ng SSTP ay nilikha mula sa mga setting ng VPN ng Windows gamit ang address ng server at mga detalye ng pagpapatunay ng operator, habang ang koneksyon ng OpenVPN ay nangangailangan ng kliyente at ng tugmang file ng configuration. Ang ispesipikasyon ng SSTP ng Microsoft ay naglalarawan ng una, at hindi naglalarawan ng handshake ng OpenVPN.

Ang port 443 ay kaginhawahan ng patakaran. Dumadaan ito sa mga network na kakaunti lang ang pinapayagan, at iyon ay tunay na kalamangan, ngunit wala itong sinasabi tungkol sa kung aling protocol ang tumatakbo sa likod nito.

Ang SSTP ay nagtutunnel ng PPP sa loob ng HTTPS

Inilalarawan ng pangalan ang konstruksyon: mga frame ng PPP na dinadala sa loob ng sesyon ng HTTPS, na nangangahulugang TLS sa ilalim at isang sertipiko na maaaring suriin ng kliyente. Isinama ito ng Windows bilang katutubong uri ng VPN, kaya ang isang pinamamahalaang laptop ay madalas na makakonekta nang walang karagdagang software maliban sa profile na ibinibigay ng operator.

Ang ibang platform ay ibang kuwento. Ang kliyente ng Linux o macOS ay nangangailangan ng pinapanatili na implementasyon, at nagkakaiba sila sa sinusuportahan at sa paraan ng pag-uulat ng mga error. Suriin ang kliyenteng talagang balak mong gamitin sa halip na ipalagay na ang built-in na kakayahan ng Windows ay maililipat, at tiyakin na ang pangalan ng server sa profile ay tumutugma sa sertipikong ipinakita ng server.

Ang SSTP ay karaniwang TCP lamang. Ang nag-iisang transport na iyon ay nakakaapekto sa pag-uugali nito sa isang link na may pagkalugi, dahil ang muling pagpapadala ay nangyayari sa loob ng tunnel at sa ilalim din nito.

Nagdadala ang OpenVPN ng sariling kliyente at pagpipilian ng transport

Nagbibigay ang OpenVPN ng sariling kliyente at profile, na nagbibigay sa iyo ng diagnostics na hindi ipinapakita ng katutubong dialog ng Windows. Maaaring makinig ang server sa UDP o TCP, at ang configuration ng operator ang nagpapasya kung alin ang dapat gamitin ng iyong kliyente. Ang profile na nakaturo sa maling transport ay nabigo bago ang pagpapatunay.

Ang pagpapatunay ay pantay na pinapatakbo ng configuration. Ang deployment ay maaaring humiling ng mga sertipiko lamang, mga sertipiko kasama ang username at password, o pangalawang factor sa ibabaw, at ang kliyente ay dapat na eksaktong tumugma sa kaayusang iyon. Ang katotohanan na ang koneksyon ay umabot sa yugto ng TLS ay hindi nagsasabi kung aling mga kredensyal ang hihilingin nito sa susunod.

Ang UDP ay ang karaniwang default dahil iniiwasan nito ang pag-nest ng isang maaasahang daloy sa loob ng isa pang maaasahang daloy. Umiiral ang TCP mode para sa mga network na humaharang sa UDP, at gumagana ito, ngunit ang mabigat na pagkalugi ay maaaring gawing mas masama ang pakiramdam kaysa sa ruta ng UDP na pinalitan nito. Piliin ang TCP kapag kailangan, hindi dahil mukhang mas maaasahan.

Pumili ayon sa kliyente, transport, at suporta

Tatlong tanong ang nagtatakda ng karamihan sa mga desisyong ito. Kailangan ba ng bawat kliyenteng device ang koneksyon na gumagana nang walang karagdagang software? Pinapayagan ba ng network na iyong umaasa ang UDP, o TCP 443 ang tanging labasan? At sino ang sumusuporta sa kliyente, sa mga update nito, at sa pagbawi nito kapag nag-expire ang profile?

Kapag inihambing ang dalawa, subukan sa parehong device at parehong network ng access. Kung ang endpoint ng SSTP at endpoint ng OpenVPN ay magkaibang server o magkaibang site, kasama sa iyong resulta ang mga rutang iyon at machine sa halip na ihiwalay ang protocol. Ito ang pinakakaraniwang paraan kung paano nagbibigay ang ganitong paghahambing ng kumpiyansa ngunit maling sagot.

Pagkatapos ay tiyakin kung alin ang aktwal na itinatag mo bago i-debug ang anupamang bagay:

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

Kahit anong paraan, tapusin sa pamamagitan ng pagsubok sa resource at DNS na kailangan mo sa halip na ideklara ang tagumpay sa estado ng tunnel. Ang parehong protocol ay maaaring i-configure na magdala lamang ng piling pribadong trapiko, at ang konektadong tunnel na walang gumaganang paglutas ng pangalan ay mukhang sirang VPN kapag sa totoo lang ito ay disenyo ng split-tunnel o DNS.

Sa isang pinamamahalaang fleet, ang pamamahagi ng profile at suporta sa update ang karaniwang nagtatakda ng tanong bago pa ang anumang pagsukat ng transport.