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