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 процената моћи ће да провери једну чињеницу уместо да понавља цео пролаз.