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 keepalive поруке не могу преживети. Обоје изгледа исто са клијентове стране, зато је фаза која је пала важнија од текста грешке.
Дељење порта 443 између веб странице и SSTP-а одлука је о рутирању, а не обећање да сваки скок обрађује оба разговора на исти начин. Ако је на путу балансер оптерећења, заштитни зид или TLS терминатор, додајте га на листу сумњивих пре него што дирнете VPN конфигурацију.
Тестирајте фазе одвојено
Извршите провере редом и зауставите се на првом неуспеху, јер свака фаза искључује други слој. TLS сонда испод одваја идентитет сертификата од свега што SSTP ради. Замените име хоста својом крајњом тачком и прочитајте subject и ланац које исписује.
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 понашања, јер подаци за пријаву никада нису затражени.