SSTP-ը TLS-ը ստուգող պրոքսիի հետևում՝ որտեղ է կտրվում սեանսը

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

Սկսեք այնտեղ, որտեղ կանգ է առնում հաճախորդը

Հաճախորդը անցնում է հաստատուն հաջորդականությամբ՝ TCP կապ 443 պորտին, TLS ձեռքսեղմում, վկայագրի ստուգում, SSTP-ի HTTP փոխանակում, PPP բանակցություն և նույնականացում, ապա IP կոնֆիգուրացիա։ Յուրաքանչյուր փուլում ձախողումը թողնում է տարբեր հետք, և դրանք խառնելը ձեզ տանում է սխալ կարգավորումների էջ։

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

Կարդացեք հաճախորդի մատյանը՝ վերջին հաջող փուլի համար, ոչ թե առաջին սխալի տողի։ Սխալի տողը սովորաբար հաղորդում է հետևանքը, մինչդեռ փուլի սահմանը նշում է մերժած բաղադրիչը։

Ինչ է SSTP-ը պահանջում ցանցից կրել

SSTP-ը աշխատում է TLS-ի վրա TCP 443-ում և ապա ուղարկում է SSTP_DUPLEX_POST անունով HTTP հարցում, որը սահմանված է SSTP բնութագրում, /sra_{GUID}/ ձևի ուղին։ Հարցումը հայտարարում է գործնականում անսահմանափակ բովանդակության երկարություն և սեանսի ողջ ընթացքում հոսքը բաց է պահում երկու ուղղությամբ։ PPP շրջանակները շարժվում են այդ հոսքի ներսում։

Այդ պատճառով սովորական զննարկում սպասարկող պրոքսին կարող է այնուամենայնիվ ձախողվել։ Վերջավոր մարմնով GET-ը կամ POST-ը կարելի է բուֆերացնել, ստուգել և փոխանցել, սակայն երբեք չավարտվող մարմնով երկկողմանի հոսքը՝ ոչ։ Պրոքսին, որը սպասում է մարմնի ավարտին, սպասում է ընդմիշտ, և հաճախորդը ի վերջո ժամանակի սպառում է ստանում։

Մեթոդների զտումը և նույնականացումը ավելացնում են իրենց ձախողման ձևերը։ Եթե պրոքսին հարցումից պահանջում է հավատարմագրեր, VPN հաճախորդը կարող է չպատասխանել, թեև զննարկիչը կպատասխաներ։ Եթե այն հեռացնում կամ վերագրում է մեթոդը, դարպասը մերժում է հարցումը մինչև PPP-ի սկիզբը։

Ինչու է ստուգումը փոխում ինքնությունը

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

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

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

Նույնականացրեք թողարկողին կարգավորումները փոխելուց առաջ

Հարցրեք վերջնակետին՝ ինչ վկայագիր է նա ներկայացնում և ով է ստորագրել այն։ Ստորև բերված հրամանները ցույց են տալիս շղթան և թողարկողին՝ առանց VPN սեանս սկսելու։

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Եթե թողարկողը հանրային CA է, ապա այս հոսթի համար կապը, հավանաբար, չի գաղտնալսվում, և ձախողումը այլ տեղ է։ Եթե թողարկողը կազմակերպության սեփական CA-ն է, ստուգումը ակտիվ է, և դարպասին հասնում են պրոքսիի միջով։ Համեմատեք մատնահետքը ցանցային թիմի սպասածի հետ, նախքան միայն անունից եզրակացություն անելը։

Զննարկիչի փորձարկումը նույն հոսթին ապացուցում է միայն, որ պրոքսին ընդունում է GET։ Այն ոչինչ չի ասում SSTP մեթոդի, հարցման URI-ի կամ մարմնի կյանքի մասին, ուստի աշխատող ինթրանեթ էջը մի ընդունեք որպես թունելի ուղու աջակցության ապացույց։

Ընտրեք աջակցվող ուղին

Հարցրեք ցանցի սեփականատիրոջը մեկ կոնկրետ հարց՝ արդյոք պրոքսին թույլ է տալիս առանց բուֆերացման երկկողմանի POST այս դարպասին 443 պորտում։ «Այո»-ն տանում է պրոքսիի բացառության կամ VPN հոսթի համար փաստաթղթավորված շրջանցման։ «Ոչ»-ը նշանակում է, որ ստուգված ուղին չի կարող կրել SSTP, և աջակցվող շտկումը այլ ուղի կամ արձանագրություն է, ոչ թե հաճախորդի ճշգրտում։

Տարբերակները սովորաբար ներառում են VPN դարպասի համար չստուգվող ելք, բաժանված թունելի ձևավորում, որը պրոքսիի միջով ուղարկում է միայն կորպորատիվ երթևեկությունը, կամ այլընտրանքային արձանագրություն, որը կազմակերպությունը աջակցում է այլ պորտում։ Յուրաքանչյուրը պատկանում է ցանցի ձևավորմանը, և յուրաքանչյուրը պետք է փորձարկվի նույն սարքով և պրոֆիլով, որպեսզի համեմատությունը մեկուսացնի ուղին։

Փաստաթղթավորեք արդյունքը՝ թողարկող, ձախողված փուլ, պրոքսիի կանոն և ընտրված ուղի։ Հաջորդ մարդը, ով կտեսնի նույն 98 տոկոսանոց կանգը, կկարողանա ստուգել մեկ փաստ՝ ամբողջ անցումը կրկնելու փոխարեն։