SSTP се проваля там, където HTTPS в браузъра успява: защо
SSTP работи в TLS на порт 443, но това не е уеб заявка. Проверявайте TCP, идентичността на TLS, обмена по SSTP и PPP удостоверяването като отделни етапи.
Браузърът отваря името на VPN хоста по HTTPS без оплакване, а клиентът SSTP все още отказва да се свърже. В тази двойка няма нищо противоречиво. SSTP използва TLS като външен транспорт и след това изпълнява собствената си заявка и PPP полезен товар в тази връзка, затова успешното зареждане на страница доказва само едно тясно нещо: хостът отговаря на GET на порт 443. Клиентът задава друг въпрос и сървърът може да му отговори зле.
Страницата се зарежда, а тунелът не
Хората прибягват до теста в браузъра, защото е бърз, и после приемат резултата като доказателство, че сървърът е достъпен и конфигуриран. Това е доказателство за GET към пътя, който адресната лента е отворила, и нищо повече. Разговорът по VPN започва след същото TLS ръкостискане, но изпраща метод и път, които уеб страница никога не използва. Затова отговор 200 за браузъра не казва нищо за това дали крайната точка на SSTP съществува.
Разделете двете наблюдения и търсенето се съкращава. Транспортът и веригата от сертификати работят, а нещо в обмена на протокола над тях не работи. Това е различно разследване от счупен порт или изтекъл сертификат и изисква различни доказателства.
Какво всъщност изпраща клиентът SSTP
Клиентът изпраща HTTP заявка с метода SSTP_DUPLEX_POST към пътя /sra_{GUID}/, после държи тялото на връзката отворено като двупосочен поток, носещ PPP кадри. Съвместимият сървър отговаря HTTP/1.1 200 и спира да се държи като уеб сървър. Всичко друго е подпис: 405 или 404 означава, че крайната точка я няма, 301 или 302 означава, че нещо пренасочва заявката, а незабавен FIN означава, че прокси или сървър е затворил потока.
Затова целта трябва да е SSTP сървър, а не уеб сървър с прикачен TLS сертификат. Методът, пътят и дълготрайното тяло са изисквания на протокола, така че обратното прокси не може да ги добави само с конфигурация. Прокси, което препредава обикновен HTTPS безупречно, пак може да откаже метод, който не разпознава.
Къде прокси или уеб сървър чупи потока
Посредникът преглежда реда на HTTP заявката, преди да препредаде нещо, и нестандартен метод с необичаен път може да не мине правилата му. Някои устройства сервират нормална страница, докато отхвърлят или прекъсват тунела, затова клиентът съобщава за връзка, която започва и после умира, вместо за чисто отхвърляне. Други приемат заявката и после прилагат таймаут за тяло или бездействие, който PPP сигналите за активност не издържат. И двете изглеждат еднакво от страната на клиента, затова етапът, който се е провалил, е по-важен от текста на грешката.
Споделянето на порт 443 между уеб сайт и SSTP е решение за маршрутизиране, а не обещание, че всеки хоп обработва двата разговора по един и същ начин. Ако в пътя има балансьор на натоварването, защитна стена или TLS терминатор, добавете го към заподозрените, преди да пипате VPN конфигурацията.
Тествайте етапите поотделно
Изпълнете проверките по ред и спрете при първия провал, защото всеки етап изключва различен слой. TLS сондата по-долу отделя идентичността на сертификата от всичко, което SSTP прави. Заменете името на хоста с вашата крайна точка и прочетете субекта и веригата, които тя отпечатва.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comСлед това съпоставете останалите доказателства с етапите, вместо да гадаете по грешката на клиента. Таблицата по-долу е контролният списък за цитиране в тикета, с подписа, който отделя един провал от следващия.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Запишете в тикета последния етап, който е успял, вместо да пишете "няма връзка". Спецификацията MS-SSTP документира заявката и PPP обмена, които следват TLS ръкостискането, и е справката за това защо тест в браузъра не може да замени нито едно от двете.
Първо идентичност, после PPP
Идентичността на TLS и PPP удостоверяването са последователни, не алтернативни, и объркването им отвежда хората до грешна настройка на сървъра. Клиентът първо проверява сертификата на сървъра и предназначението му, после PPP договаря своето състояние и удостоверява потребителя с метод предизвикателство-отговор или EAP. Проблем със сертификата дава различна грешка от отхвърлена парола и нито една от двете грешки не описва етапа, който покрива другата.
Смяната на името на хоста с адрес или прескачането на предупреждението за сертификата премахва проверката, която би открила проваления етап, вместо да го поправи. Задръжте предупреждението и го прочетете. Не нулирайте PPP парола, когато HTTP обменът така и не е стигнал до поведението на SSTP, защото идентификационните данни никога не са били поискани.