Ինչպե՞ս է OpenConnect-ը մուտքի քուքին վերածում թունելի։

OpenConnect-ը միավորում է երկու առանձին փոխանակում մեկ կարճատև արժեքով՝ վեբ մուտքը և VPN թունելը։ Առաջին փոխանակումը սովորական HTTPS է՝ հավատարմագրերը, SAML շրջագայությունը կամ թոքենը գնում են դարպասին, և պատասխանը բերում է նույնականացման քուքի։ Երկրորդ փոխանակումը նույն դարպասին է ներկայացնում այդ քուքին որպես ապացույց, որ վեբ փուլն արդեն տեղի է ունեցել, և միայն դրանից հետո է բարձրանում թունելը։

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

Ինչ են հերթով փոխանակում հաճախորդն ու դարպասը

Նույնականացման փուլը սովորական պաշտպանված կայքի տեսք ունի։ OpenConnect-ը ուղարկում է օգտատիրոջ հավատարմագրերը կամ հետևում է դարպասի վերահղմանը դեպի ինքնության մատակարար, և դարպասը պատասխանում է փաստաթղթով, որը ներառում է նույնականացման քուքին։ AnyConnect արձանագրությունում այդ արժեքը գնում է քուքի վերնագրում հաջորդ հարցումների ժամանակ, սովորաբար webvpn-ի նման անվան տակ, և ձեռնարկը այն համարում է սեսիան առաջ տանող հավատարմագիր։

Երկրորդ փուլը CONNECT հարցում է դարպասի VPN վերջնակետին՝ այդ քուքին կցված։ Դարպասը ստուգում է այն, նշանակում հասցե, և հաճախորդը սկսում է CSTP-ն TLS-ի վրա, իսկ DTLS-ը ընտրովի ավելի արագ տվյալների ուղի է, երբ սեսիան արդեն կա։ Միայն այս պահին են հաստատվում թունելի պարամետրերը, երթուղիները, DNS կարգավորումները և սեսիայի երթևեկության բանալիները։ Քուքին հաճախորդին անցկացրեց դռնով, բայց ոչինչ չգաղտնագրեց։

Այս հերթականությունը բացատրում է, թե ինչու գոյություն ունի openconnect --authenticate-ը։ Գործարկեք այն, և այն կատարում է վեբ փուլը, տպում է փոքր բլոկ shell փոփոխականների, ինչպիսիք են COOKIE-ն, HOST-ը, CONNECT_URL-ը և FINGERPRINT-ը, ապա դուրս է գալիս մինչև որևէ թունելի կառուցումը։ Դրանից հետո փաթաթող սկրիպտը կարող է այդ արժեքներով սկսել իրական կապը, և դա հենց այն բաժանումն է, որն անհրաժեշտ է առանց գլխի կամ երկու կոնտեյների տեղակայմանը։

Քուքին սեսիայի կրիչ է, ոչ բանալի

Վերաբերվեք արժեքին այնպես, ինչպես վերաբերվում եք սեսիայի նույնացուցչին վեբ հավելվածում։ Ով իր կյանքի ընթացքում պահում է այն, կարող է դարպասից պահանջել այն թունելը, որին իրավունք ունի այդ սեսիան, ուստի դրա գաղտնիությունը կարևոր է։ Բայց պատճենելը չի բացահայտում երթևեկությունը, որովհետև թունելի գաղտնիությունը գալիս է TLS ձեռքսեղմումից և ածանցյալ բանալիներից, ոչ թե քուքի տողից։

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

Քուքին մի դիտեք որպես այլ հավատարմագրերի համընդհանուր փոխարինող։ SAML պնդումը, դիտարկիչի գաղտնաբառը և այլ ծառայության թողարկած քուքին տարբեր լսարաններով տարբեր օբյեկտներ են, և մեկը մյուսի դաշտում դնելը սովորաբար ձախողվում է դարպասի մոտ կամ ավելի վատ՝ հաջողվում է սխալ վստահության սահմանի դեմ։

Քուքին փոխանցել առանց պատճեններ թողնելու

Linux-ում ամենաապահով մեխանիկական հանձնումը ստանդարտ մուտքն է։ --cookie-on-stdin-ը արժեքը կարդում է stdin-ից, ուստի քուքին երբեք չի հայտնվում գործընթացի փաստարկների ցանկում, որտեղ ցանկացած տեղական օգտատեր կարող է կարդալ այն ps-ով։ Խողովակաշարը, որը նույնականացնում է մի գործընթացում և սնուցում թունելը մյուսում, արժեքը պահում է խողովակում, ոչ թե ֆայլում կամ միջավայրի փոփոխականում։

Փաստարկներն ու միջավայրի փոփոխականները տարբեր պատճառներով ավելի թույլ են։ Փաստարկը տեսանելի է գործընթացների աղյուսակում հաճախորդի ողջ կյանքի ընթացքում և հաճախ հայտնվում է shell-ի պատմության մեջ։ Միջավայրի փոփոխականը ժառանգվում է զավակ գործընթացներին, և այն systemd միավորը, որը սահմանում է այն միավորի ֆայլում, գաղտնիքը պահում է ընթեռնելի կազմաձևում։ Եթե ֆայլն անհրաժեշտ է, սահմանափակեք այն ծառայության հաշվով և ջնջեք սեսիայի ավարտին։

Արտոնությունների սահմանը նույնպես դիտավորյալ պահեք։ Այն գործընթացը, որը խոսում է ինքնության մատակարարի հետ և գուցե բացում դիտարկիչ, պետք է աշխատի որպես այն օգտատերը, ում պատկանում է այդ մուտքը։ Այն գործընթացը, որը կարգավորում է երթուղիները, DNS-ը և թունելի սարքը, կարող է ավելի շատ արտոնությունների կարիք ունենալ։ Ամբողջ դիտարկիչը որպես root աշխատեցնելը, որպեսզի նրա քուքին հասանելի լինի root-ին պատկանող թունելին, սխալ փոխանակում է, և ժամանակակից OpenConnect տեղակայումները կարող են արժեքը բացահայտ փոխանցել այդ սահմանով։

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

Ստուգում և ժամկետի լրանալ երկրորդ փուլում

Երկրորդ փուլը դեռ պետք է ստուգի սերվերը։ FINGERPRINT-ը, որը տպում է --authenticate-ը, վկայագրի ամրացում է pin-sha256: ձևով, և այն --servercert-ով թունելի կանչին փոխանցելը ստուգումը պահում է ամրացված այն դարպասին, որի դեմ նույնականացել եք։ Վկայագրի ստուգումն անջատելը սկրիպտը պարզեցնելու համար վերացնում է միակ ապացույցը, որ քուքին հանձնվում է նախատեսված հոսթին։

Երբ դարպասը մերժում է քուքին, լուծումը նոր նույնականացման փուլն է, ոչ թե ավելի երկար պահոցը։ Պահեք քուքին միայն կապի կյանքի ընթացքում, ջնջեք ժամանակավոր ֆայլերը դուրս գալիս և օգտագործեք ինքնության մատակարարի կամ դարպասի սեսիան հեռացնելու գործընթացը, երբ սեսիան բացահայտվում է կամ սարք է կորչում։ Պահոցում դրված քուքին MFA-ից ազատում չէ։

Մինչ այս ամենը ավտոմատացնելը ստուգեք չորս բան՝ թունելը աշխատում է ճիշտ հաշվով, քուքին գալիս է stdin-ով, վկայագրի մատնահետքը ամրացված է, և սեսիան դեն է նետվում, երբ թունելը փակվում է։ Եթե դրանցից որևէ մեկը բացակայում է, ավտոմատացումը ընդլայնել է վստահությունը քուքի նկատմամբ՝ ձեռքի ընթացքը վերարտադրելու փոխարեն։