SSTP против OpenVPN-а: исти порт 443, други протокол

Обе опције могу стајати иза TCP 443, па људи претпостављају да су то заменљиве крајње тачке. Нису: SSTP сервер говори PPP унутар HTTPS-а, док OpenVPN сервер говори сопствени протокол преко TLS-а или сировог UDP тока. Усмеравање једног клијента на порт другог даје везу која никада не стигне до позива за пријаву. Избор се односи на то који клијент и пренос можете да подржите, а не на број.

Заједнички порт не чини заједнички протокол

TLS руковање може се завршити и ипак не водити никуда, јер се после тога клијент и сервер не слажу шта рећи даље. У снимку пакета видите чисто руковање након којег следе подаци апликације које друга страна одбија или игнорише. Тај образац је потпис несагласја протокола, а не блокаде заштитног зида.

Ни преименован профил ни друга ставка менија не претвара једно у друго. SSTP веза се ствара у Windows VPN подешавањима са адресом сервера и подацима за проверу идентитета оператера, док OpenVPN веза тражи клијента и одговарајућу конфигурациону датотеку. Microsoft-ова SSTP спецификација описује прво и не описује OpenVPN руковање.

Порт 443 је погодност политике. Пролази кроз мреже које дозвољавају мало шта друго, и то је стварна предност, али не говори ништа о томе који протокол ради иза њега.

SSTP тунелује PPP унутар HTTPS-а

Назив описује конструкцију: PPP оквири који се преносе унутар HTTPS сесије, што значи TLS испод и сертификат који клијент може да провери. Windows то укључује као изворни тип VPN-а, па управљани преносни рачунар често може да се повеже без додатног софтвера осим профила који оператер даје.

Друге платформе су друга прича. Linux или macOS клијент тражи одржавану имплементацију, а оне се разликују по томе шта подржавају и како пријављују грешке. Проверите клијента који стварно намеравате да користите уместо да претпоставите да се уграђена могућност Windows-а преноси, и потврдите да се назив сервера у профилу поклапа са сертификатом који сервер представља.

SSTP је обично само TCP. Тај једини пренос утиче на понашање на вези са губицима, јер се поновно слање дешава и унутар тунела и испод њега.

OpenVPN доноси сопственог клијента и избор преноса

OpenVPN испоручује сопственог клијента и профил, што вам даје дијагностику коју изворни Windows дијалог не приказује. Сервер може да слуша на UDP-у или TCP-у, а конфигурација оператера одређује који ваш клијент мора да користи. Профил усмерен на погрешан пренос пада пре провере идентитета.

Провера идентитета подједнако зависи од конфигурације. Постављање може да захтева само сертификате, сертификате плус корисничко име и лозинку или други фактор поврх тога, а клијент мора тачно да одговара том распореду. Чињеница да веза стигне до TLS фазе не говори које ће акредитиве тражити даље.

UDP је уобичајени подразумевани избор јер избегава угњежђивање поузданог тока у други поуздан ток. TCP режим постоји за мреже које блокирају UDP и ради, али велики губици могу да га учине горим од UDP пута који је заменио. Изаберите TCP када морате, не зато што звучи поузданије.

Изаберите према клијенту, преносу и подршци

Три питања решавају већину ових одлука. Да ли је сваком клијентском уређају потребна веза која ради без додатног софтвера? Да ли мрежа на коју се ослањате дозвољава UDP, или је TCP 443 једини излаз? И ко подржава клијента, његова ажурирања и његов опоравак када профил истекне?

Када упоређујете њих двоје, тестирајте на истом уређају и истој приступној мрежи. Ако су SSTP и OpenVPN крајње тачке различити сервери или различита места, ваш резултат укључује те путеве и машине уместо да изолује протокол. То је најчешћи начин на који таква поређења дају самоуверен, али погрешан одговор.

Затим потврдите коју сте стварно успоставили пре него што почнете да отклањате било шта друго:

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

Како било да било, завршите тестирањем ресурса и DNS-а који вам требају уместо да прогласите успех у стању тунела. Оба протокола могу да се конфигуришу да преносе само изабрани приватни саобраћај, а повезан тунел без исправног разрешавања имена изгледа као покварен VPN када је у ствари пројекат подељеног тунела или DNS-а.

У управљаном парку дистрибуција профила и подршка за ажурирања обично решавају питање много пре било каквог мерења преноса.