Ընտրել կայուն գրանցման աղբյուր GET VPN անդամների համար

Ինչ-որ մեկը խմբի անդամի գրանցումը ուղղում է loopback հասցեի և հայտարարում, որ GET VPN-ի անկայունությունը լուծված է։ Երբեմն այդպես է։ Հաճախ loopback-ը հասանելի է միայն անդամի սեփական երթուղային աղյուսակից և ոչ մի այլ տեղից, ուստի գրանցումը կրկին կոտրվում է հաջորդ անգամ, երբ այն կրող uplink-ը տատանվում է։ Գրանցման հասցեն ինքնություն է կառավարման հարթությունում, և այն օգնում է միայն այն ժամանակ, երբ երկու ուղղությամբ գոյություն ունի իրական ուղի։ Այն գիտակցաբար ընտրելը արժե, և դա ավելի փոքր փոփոխություն է, քան հուշում է ժողովրդական պատմությունը։

Ինչ է նույնականացնում գրանցման հասցեն

GDOI տեղադրման մեջ խմբի անդամը գրանցվում է բանալիների սերվերում և նրանից ստանում է խմբի քաղաքականությունը։ Այն հասցեն, որը սերվերը գրանցում է, այդ զրույցի համար անդամի ինքնությունն է։

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

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

Loopback-ը այնքան լավն է, որքան իր երթուղին

Loopback-ը անդամին տալիս է տրամաբանական հասցե, որը չի անհետանում, երբ մեկ ֆիզիկական uplink-ը ձախողվում է։ Դա իրական առավելություն է երթուղիչում, որն ունի մի քանի ուղի դեպի բանալիների սերվեր։

Բայց դա նաև ընդամենը հասցե է։ Եթե բանալիների սերվերը հետադարձ երթուղի չունի դեպի այն, գրանցումը ձախողվում է ճիշտ ինչպես առաջ։ Եթե անդամի երթուղային աղյուսակը հասնում է սերվերին միայն մեկ uplink-ի միջոցով, loopback-ը կայուն է, իսկ ուղին՝ ոչ։

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

Առանձին պահեք կառավարումը և պաշտպանված տրաֆիկը

Cisco-ի GDOI շրջանցման ուղեցույցը նկարագրում է գրանցման ինտերֆեյսը և գրանցման ու շրջանցման մշակման միջև կապը։ Կարդացեք այն թողարկման վարքը, որը դուք իրականում գործարկում եք, փոխարենը մեկ արտահայտությունը համընդհանուր հրաման համարելու։

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

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

Ստուգեք ինքնությունը անցման ընթացքում

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

Ինչ ուզում եք տեսնել, այն է, որ նախատեսված տրամաբանական վերջնակետը դեռ հասանելի է և դեռ ներկայացված է այնպես, ինչպես նախագծել եք։ Ինչ չեք ուզում տեսնել, այն է երկրորդ գրանցումը այնպիսի հասցեից, որը չեք նախատեսել, քանի որ հենց այդպես են առաջանում անդամի կրկնօրինակ գրառումները։

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

Ինչ չի շտկում կայուն աղբյուրը

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

Ինչ անում է, այն է հեռացնում մեկ փոփոխական՝ ինքնությունն այլևս չի փոխվում, երբ փոխվում է uplink-ի հասցեն։ Դա արժե ունենալ, և դա նախագծի մեկ տող է, ոչ ամբողջ նախագիծը։

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