SSTP зад прокси, което проверява TLS: къде се къса сесията

Браузърът ви зарежда корпоративния интранет, сертификатът на проксито е доверен, а клиентът на SSTP все още прекъсва близо до края на връзката. Този модел сочи към разликата между уеб заявка и тунелна сесия, а не към грешна парола. Проследете връзката от TCP нагоре и отбележете първия етап, който се проваля. Етапът, а не кодът за грешка, ви казва дали проксито е причината.

Започнете там, където клиентът спира

Клиентът преминава през фиксирана последователност: TCP връзка към порт 443, TLS ръкостискане, проверка на сертификата, HTTP обмен на SSTP, PPP договаряне и удостоверяване, след това IP конфигурация. Провалът на всеки етап оставя различна следа и объркването им ви отвежда до грешна страница с настройки.

TCP провал е изчакване или нулиране, преди да се появи какъвто и да е TLS байт. TLS провал е предупреждение или изчакване на ръкостискане. Провал на сертификата дава предупреждение за веригата или името. HTTP провал идва след успешно ръкостискане, често като код за състояние или незабавно затваряне. PPP провал идва, след като тунелът е технически установен, затова изглежда като проблем с удостоверяването.

Четете журнала на клиента за последния успешен етап, а не първия ред с грешка. Редът с грешка обикновено съобщава последствието, докато границата на етапа назовава компонента, който е отказал.

Какво SSTP иска от мрежата да носи

SSTP работи през TLS на TCP 443 и след това изпраща HTTP заявка SSTP_DUPLEX_POST, дефинирана в спецификацията на SSTP, към път от вида /sra_{GUID}/. Заявката обявява практически неограничена дължина на съдържанието и държи потока отворен в двете посоки за целия живот на сесията. PPP кадрите пътуват вътре в този поток.

Ето защо прокси, което обслужва обикновено сърфиране, пак може да се провали. GET или POST с краен обем може да се буферира, проверява и препраща; дуплексен поток с тяло, което никога не свършва, не може. Прокси, което чака тялото да завърши, чака вечно и клиентът в крайна сметка получава изчакване.

Филтрирането на методи и удостоверяването добавят свои режими на провал. Ако проксито поиска идентификационни данни, VPN клиентът може да не отговори, въпреки че браузърът би отговорил. Ако премахне или пренапише метода, шлюзът отхвърля заявката, преди PPP да започне.

Защо проверката променя идентичността

Прокси, което проверява TLS, прекратява TLS връзката на клиента и отваря отделна връзка към шлюза. Затова клиентът проверява сертификата на проксито, а не този на шлюза, и шлюзът вижда проксито като свой партньор. Когато организацията разпространява собствения си корен, браузърът и VPN клиентът може да приемат тази верига, така че ръкостискането успява и проблемът се премества на следващия етап.

Успешната проверка не означава, че проксито може да носи сесията. То все още трябва да препредава неограничен двупосочен POST без буфериране и да поддържа двете връзки живи с часове. Много продукти за проверка са изградени за трафик заявка-отговор и се справят зле или изобщо не се справят с този случай.

Ето защо добавянето на непознат корен или изключването на проверката е грешен ремонт. Това променя кой сертификат приема клиентът; не прави нищо за обработката на потока, която всъщност е счупила сесията.

Определете издателя, преди да променяте настройки

Попитайте крайната точка какъв сертификат представя и кой го е подписал. Командите по-долу показват веригата и издателя, без да стартират VPN сесия:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Ако издателят е публичен CA, връзката вероятно не се прихваща за този хост и провалът е другаде. Ако издателят е собственият CA на организацията, проверката е активна и шлюзът се достига през прокси. Сравнете отпечатъка с този, който мрежовият екип очаква, преди да правите извод само от името.

Тест в браузър към същия хост доказва само, че проксито приема GET. Той не казва нищо за метода SSTP, URI на заявката или живота на тялото, затова не приемайте работеща интранет страница като доказателство, че тунелният път се поддържа.

Изберете поддържания път

Задайте на собственика на мрежата един конкретен въпрос: позволява ли проксито небуфериран дуплексен POST към този шлюз на порт 443? „Да“ води до изключение в проксито или документиран обход за VPN хоста. „Не“ означава, че провереният път не може да носи SSTP и поддържаната поправка е друг път или протокол, а не промяна в клиента.

Опциите обикновено включват непроверен изход за VPN шлюза, проект за разделен тунел, който изпраща само корпоративния трафик през проксито, или алтернативен протокол, който организацията поддържа на друг порт. Всяка принадлежи на мрежовия дизайн и всяка трябва да се тества със същото устройство и профил, за да изолира сравнението пътя.

Документирайте резултата: издател, провален етап, правило на проксито и избран път. Следващият човек, който види същото забавяне при 98 процента, ще провери един факт, вместо да повтаря цялото преминаване.