SSTP — гэта PPP праз HTTPS, а не вэб-старонка на порце 443

SSTP перадае PPP унутры HTTPS-злучэння, таму для ўсяго пасярэдзіне гэта выглядае як вэб-трафік. TLS і HTTP ствараюць знешні канал, затым кантрольныя паведамленні SSTP рыхтуюць тунель, а PPP забяспечвае паводзіны сесіі. Браўзер, які загружае старонку па тым жа адрасе прайшоў толькі частку першага этапу. Калі лічыць гэта тэстам VPN, працоўны проксі атрымлівае віну за неадпаведнасць пратаколу.

Прайдзіце чатыры этапы па парадку, і збой, які вы бачыце, апынецца на адным з іх.

Этап 1: TCP і TLS

Кліент адкрывае TCP-злучэнне да порта 443 і выконвае TLS-рукапоціск. Ланцуг сертыфікатаў мусіць адпавядаць імені хоста, з якім быў наладжаны кліент. Неадпаведнасць імені тут дае збой яшчэ да абмену любым паведамленнем SSTP, а спецыфікацыя SSTP мяркуе, што гэты знешні HTTPS-канал ужо існуе. Нішто на наступных этапах не кампенсуе збой даверу тут.

Звычайны вэб-сервер можа бездакорна прайсці гэты этап і ўсё роўна праваліць наступны. Поспех TLS — гэта доказ пра сертыфікат, а не пра пратакол за ім.

Этап 2: HTTPS-запыт

SSTP робіць свой запыт пэўным метадам, SSTP_DUPLEX_POST, і трымае абмен адкрытым замест вяртання дакумента. Сервер або проксі, наладжаныя на звычайныя запыты старонак, могуць прыняць злучэнне і затым адхіліць метад. Гэтае адхіленне і ёсць праблема сумяшчальнасці, якую людзі звычайна апісваюць як блокіроўку порта 443.

Чытайце код адказу і метад у журнале сервера. Адхіленне на гэтым этапе — іншая праблема, чым тайм-аўт TCP, і яны вядуць да розных выпраўленняў.

Этап 3: кантрольныя паведамленні

Пасля прыняцця запыту SSTP абменьваецца кантрольнымі паведамленнямі, якія ўзгадняюць і рыхтуюць тунель. Гэта пратакольныя паведамленні ўнутры цела HTTPS, а не HTTP-запыты, таму проксі, які аглядае і перапісвае целы, можа іх зламаць, пакінуўшы запыты старонак некранутымі.

Менавіта тут прылада глыбокага агляду заслугоўвае сваю рэпутацыю. Калі старонкі загружаюцца, а VPN не працуе, праверце, ці змяняецца цела, а не ці адкрыты порт.

Этап 4: PPP бярэ кіраванне

Затым PPP забяспечвае паводзіны сесіі: узгадненне злучэння, аўтэнтыфікацыю і наступную наладку сеткавага ўзроўню. Аўтэнтыфікацыя PPP асобная ад праверкі TLS, якую кліент ужо прайшоў. Сертыфікат сервера, які кліент прымае, нічога не кажа пра тое, ці сапраўдныя ўліковыя даныя карыстальніка і ці аўтарызаваны ўліковы запіс.

Прыняты сертыфікат і адхілены ўваход не супярэчаць адзін аднаму. Гэта паслядоўныя этапы з незалежнымі вынікамі.

Аўтэнтыфікацыя мае некалькі роляў

Кліент правярае ідэнтычнасць TLS-сервера па сваім сховішчы даверу і наладжаным імені. Затым PPP аўтэнтыфікуе карыстальніка або машыну ў залежнасці ад разгортвання. Сервер можа дадаць сваю палітыку пра тое, каму можна падключацца і чаго дасягаць. Трымайце імя хоста ўзгодненым з ідэнтычнасцю сертыфіката, бо замена на сыры адрас ператварае працоўную наладку ў збой праверкі імені.

Запішыце, які этап паведаміў пра збой. Сертыфікат, метад, кантрольнае паведамленне, аўтэнтыфікацыя PPP, затым маршруты: пяць месцаў, пяць выпраўленняў.

Што тэст браўзера можа і не можа паказаць

Загрузка старонкі па адрасе даказвае развязанне DNS, дасягальнасць TCP і наяўнасць чагосьці, што слухае і гаворыць па HTTP. Яна не даказвае, што метад прыняты, абмен кіравання вытрымлівае або аўтэнтыфікацыя PPP наладжана. Выкарыстоўвайце кліент, які рэалізуе SSTP, замест пераробкі іншага профілю праз змену порта.

Пасля ўзняцця сесіі маршруты, DNS і перадача на баку сервера ўсё яшчэ вызначаюць, чаго карыстальнік можа дасягнуць. Тунель — гэта шлях, а не дазвол.