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 проценти ќе може да провери еден факт наместо да ја повторува целата прошетка.