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-ը և սերվերի կողմի փոխանցումը դեռ որոշում են, թե ինչի կարող է հասնել օգտվողը։ Թունելը ուղի է, ոչ լիազորում։