GDOI. ինչու բանալիների սերվերը ձեր տվյալների ուղու վրա չէ

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

Անվտանգության վիճակի երկու տեսակ

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

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

Հետևեք փոխանակումներին, ոչ թե գծագրին

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

Ահա թե ինչու ֆիզիկական հարակցությամբ գծված ինտերֆեյսների գծագիրը այստեղ մոլորեցնում է։ Վերահսկիչի ինտերֆեյսը կառավարման աղբյուր է, ոչ թե ինքնաբերաբար յուրաքանչյուր գաղտնագրված փաթեթի հաջորդ ցատկը։

Երեք գրառում, որ արժե պահել

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

Պահեք դրանք կոնֆիգուրացիայի կողքին, ոչ թե ինչ-որ մեկի հիշողության մեջ։ Անդամակցության փոփոխությունները բավական հազվադեպ են, որ հիմնավորումը միշտ անհետացել է մինչև այն պահը, երբ պետք է։

Ինտերֆեյս, ծառայության միացում, մշակման ուղի

Ծառայությունների վրա հիմնված դարպասում ևս մեկ տարբերություն կա՝ ֆիզիկական հիմքի հասցեն նույնը չէ, ինչ տեղական ծառայության միացումը, և հարթակի իրականացումը որոշում է, թե ինչպես է երթևեկությունը հասնում նրա IPsec մշակման ուղուն։ Ծառայությունը ֆիզիկական ինտերֆեյս տեղափոխելը կամ անկապ թարգմանություն ավելացնելը, որովհետև սխալի հաղորդագրությունը հիշատակել է ծառայության ինտերֆեյսի կանոն, վերանորոգման հագուստով ենթադրություն է։

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

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

Կառավարման հասանելիությունը և տվյալների փոխանցումը առանձին ստուգումներ են

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

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