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 и препращането от страна на сървъра все още решават до какво може да стигне потребителят. Тунелът е път, а не разрешение.