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 однесувањето, бидејќи акредитивите никогаш не биле побарани.