SSTP-ը սկզբում նույնականացնում է սերվերը, ապա՝ օգտատիրոջը

SSTP հաճախորդը կարող է ավարտել TLS-ը և այնուամենայնիվ մերժել օգտատիրոջը մեկ վայրկյան անց։ Այդ հաջորդականությունը սխալ չէ, դա արձանագրային կույտն է՝ սկզբում տրանսպորտի անվտանգությունը, ապա օգտատիրոջ նույնականացումը։ Քանի որ երկու փուլերը ձախողվում են տարբեր հաղորդագրություններով, դրանք տարբեր ուղղումներ էլ են պահանջում։ Թե որ փուլն է առաջացրել սխալը, կարդալը ախտորոշման մեծ մասն է։

Վստահելի վկայականը ապացուցում է վերջնակետը. այն ոչինչ չի ասում հաշվի մասին։

Ինչ է հաստատում TLS բարևափոխանակությունը

Հաճախորդը ստուգում է սերվերի ներկայացրած վկայականը իր վստահության պահոցի, պահանջված հոսթի անվան, վավերականության պատուհանի և հարթակի կիրառած ցանկացած լրացուցիչ քաղաքականության դեմ։ Դա պաշտպանում է կապը նախատեսված վերջնակետի հետ։ Բայց չի ապացուցում, որ կոնկրետ հաշիվը միացված է, չի լրացել կամ լիազորված է հեռավոր մուտքի համար։ Դրանք առանձին հարցեր են, որոնք ավելի ուշ տալիս է մեկ այլ բաղադրիչ։

Այդ իսկ պատճառով վկայականի ստուգումները հեռացնելը՝ մուտքի հուշումին հասնելու համար, սխալ ուղղում է։ Դուք ստանում եք մուտքի հուշում մի կապի վրա, որը չեք կարող ստուգել։ Վկայականի սխալը վերաբերում է հոսթի անվանը, ժամացույցին, շղթային կամ վստահության կարգավորումներին։

Ինչ են ավելացնում SSTP-ն և PPP-ն վերևում

SSTP-ն աշխատում է HTTPS-ի վրա և իր մեջ կրում է PPP՝ իր սեփական կառավարման փոխանակությամբ կապի շուրջ։ Այնուհետև PPP-ն կատարում է իր կապի և նույնականացման փուլերը, իսկ նույնականացման մեթոդը կախված է սերվերի քաղաքականությունից և հաճախորդի հնարավորություններից։ PAP, CHAP, MS-CHAPv2 և EAP-ը բոլորն էլ PPP նույնականացման տարբերակներ են՝ շատ տարբեր հատկություններով։ VPN-ի օգտատիրոջ ստուգումը հենց այդ PPP փուլն է, ոչ թե դրա տակ գտնվող TLS շերտը։

Ուստի օգտատիրոջ մերժումը կարող է նշանակել հավատարմագրեր, հաշվի սահմանափակում կամ մեթոդի անհամապատասխանություն։

Սերվերի կողմի պատճառը շատ ավելի օգտակար է, քան պրոֆիլի բոլոր գաղտնիքների վերակայումը։ Հաշվի անջատման դեպքը և մեթոդի շուրջ բանակցությունների ձախողումը հաճախորդի մոտ նման են երևում, իսկ սերվերում ոչ մի ընդհանուր բան չունեն։

Համապատասխանեցրեք սխալը փուլին

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

Նույն հավասարեցումը կարևոր է սերվերի կողմում, որտեղ նույնականացման գրառումը և տրանսպորտի մատյանը հաճախ առանձին ֆայլեր են՝ առանձին ժամացույցներով։ Երկու րոպեի շեղումը բավական է, որպեսզի ակնհայտ պատճառը անհնար թվա։

Մուտքից հետո լիազորումը դեռ առանձին է

Հաջող մուտքը չի տալիս բոլոր մասնավոր ռեսուրսները։ Երթուղիները որոշում են, թե ինչ հասանելի է, DNS-ը որոշում է, թե ինչ է լուծվում, և յուրաքանչյուր ծառայություն դեռ կիրառում է իր սեփական թույլտվությունները։ Միացված ցույց տվող նստաշրջանը հայտարարություն է թունելի մասին, ոչ թե ֆայլերի համօգտագործման։ Երբ օգտատերը կարող է միանալ և չի կարող հասնել մեկ հոսթի, թունելի փուլն արդեն ավարտված է։

Դա նույն շերտավորումն է, որը ցույց տվեց բարևափոխանակությունը՝ մեկ մակարդակ վերև։

Հաշվի վերականգնումը պահեք օպերատորի աջակցվող ընթացակարգում՝ փոխարենը տրանսպորտի պարամետրերը փոխելով ի պատասխան օգտատիրոջ բացահայտ մերժման։ Անջատված հաշիվը շտկելու համար տրանսպորտը փոխելը այնպիսի ուղղում է, որը կարծես աշխատում է, երբ հաշիվը նորից միացվում է անկապ պատճառով։