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