Դիտարկիչը բացում է 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

Ապա քարտեզագրեք մնացած ապացույցները փուլերին՝ փոխարենը գուշակելու հաճախորդի սխալից։ Ներքևի աղյուսակը տոմսում մեջբերելու ստուգաթերթն է՝ ստորագրությամբ, որն առանձնացնում է մի ձախողումը հաջորդից։

StageWhat it provesFailure signature
TCP to 443A listener exists and the path is openTimeout or connection refused
TLS with SNIThe certificate matches the name you useName mismatch or untrusted chain
SSTP_DUPLEX_POST exchangeThe endpoint is an SSTP server405, 404, 301 or an early FIN
PPP authenticationThe user credential was acceptedAuth failure after a 200 response
Inner routingA permitted destination is reachableTunnel up, no reply from the target

Տոմսում գրանցեք վերջին հաջողված փուլը՝ "չի կարող միանալ" գրելու փոխարեն։ MS-SSTP բնութագրությունը փաստաթղթավորում է TLS ձեռքսեղմումից հետո եկող հարցումը և PPP փոխանակումը, և դա է հղումը, թե ինչու դիտարկիչի թեստը չի կարող փոխարինել դրանցից ոչ մեկին։

Նախ ինքնությունը, ապա PPP

TLS ինքնությունը և PPP նույնականացումը հաջորդական են, ոչ այլընտրանքային, և դրանք շփոթելը մարդկանց ուղարկում է սխալ սերվերի կարգավորման։ Հաճախորդը նախ վավերացնում է սերվերի վկայագիրը և դրա նախատեսված նպատակը, ապա PPP-ն բանակցում է իր վիճակը և նույնականացնում օգտատիրոջը մարտահրավեր-պատասխան մեթոդով կամ EAP-ով։ Վկայագրի խնդիրը տալիս է այլ սխալ, քան մերժված գաղտնաբառը, և ոչ մի սխալ չի նկարագրում այն փուլը, որը ծածկում է մյուսը։

Հոսթի անունը հասցեով փոխարինելը կամ վկայագրի զգուշացումը շրջանցելը հեռացնում է այն ստուգումը, որը կբացահայտեր ձախողված փուլը՝ փոխարենը այն ուղղելու։ Պահեք զգուշացումը և կարդացեք այն։ Չվերակայեք նաև PPP գաղտնաբառը, երբ HTTP փոխանակումը երբեք չի հասել SSTP վարքագծին, որովհետև հավատարմագրերը երբեք չեն հարցվել։

Առնչվող հոդվածներ