Ամպային VPN-ին անհրաժեշտ է BGP. ինչու են մյուս երթուղավորման արձանագրությունները ձախողվում

IPsec անվտանգության ասոցիացիան միացված է, թունելի հաշվիչները շարժվում են, և ամպային նախդիրին ուղղված թրաֆիկը անհետանում է։ Օպերատորն այնուհետև փորձում է միացնել OSPF-ը հաճախորդի երթուղիչում՝ սպասելով, որ հարևանը ձևավորվի, և ոչինչ չի պատահում։ Թունելը երբեք բացակայող մասը չէր. կառավարվող ամպային VPN-ը տրամադրում է սահմանված երթուղավորման պայմանագիր, և խոշոր պլատֆորմներում այդ պայմանագիրը BGP-ն է։ Քանի դեռ սեսիա չկա և նախդիր չի ընդունվել, թունելը պարզապես կոդավորված ուղի է՝ առանց հետևում նպատակակետերի։

Թունելը միացված է, իսկ երթուղին բացակայում է

1-ին և 2-րդ փուլերի ավարտը վկայում է, որ կողմերը համաձայն են պաշտպանության շուրջ, ոչ թե որ կողմը գիտի՝ ուր ուղարկել թրաֆիկը։ Դրանք առանձին վիճակի մեքենաներ են՝ առանձին խափանման ռեժիմներով։

Տվեք երեք հարց հերթականությամբ. արդյո՞ք նախդիրը հայտարարվել է, արդյո՞ք հարևանն ընդունել է այն, և արդյո՞ք այն տեղադրվել է փոխանցման համար։ Հայտարարված և զտված նախդիրը քաղաքականության խնդիր է։ Երբեք չհայտարարված նախդիրը սեսիայի կամ կարգավորման խնդիր է։ Ընդունված, բայց չտեղադրված նախդիրը երթուղու ընտրության խնդիր է, և յուրաքանչյուր պատասխան մատնանշում է կարգավորման տարբեր մասը։

Ինչ է իրականում տալիս մատակարարը

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

Google Cloud-ը փաստաթղթավորում է դինամիկ BGP երթուղավորումը HA VPN-ի համար, որտեղ Cloud Router-ը սովորում է հարևանների երթուղիները և VPC-ին մատակարարում է համապատասխան հատուկ դինամիկ երթուղիներ։ AWS Site-to-Site VPN-ը փաստաթղթավորում է ընտրություն ստատիկ և դինամիկ երթուղավորման միջև և նկարագրում է BGP կենսունակության ստուգումները որպես օգտակար թունելի փոխարկման համար՝ միաժամանակ աջակցելով առողջության ստուգումներին BGP չունեցող սարքերի համար։ Ոչ մի պլատֆորմի վարք չպետք է եզրակացվի մյուսի արտադրանքի անունից։

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

Թունելի պաշտպանությունը և հասանելիությունը առանձին աշխատանքներ են

IPsec-ը պաշտպանում է թունելի համար ընտրված թրաֆիկը։ BGP-ն ապահովում է հասանելիության տեղեկատվությունը, որը նախդիրը դարձնում է համապատասխան։ Աշխատող թունելը չի ապացուցում, որ ակնկալվող նախդիրը հայտարարվել, ընդունվել կամ տեղադրվել է։

Պատկերացրեք մասնաճյուղ, որը 10.42.0.0/16-ը հայտարարում է երկու համապատասխան թունելային ուղիներով։ Հեռացրեք մեկ օգտագործելի ուղին, և երթուղու ընտրությունը կարող է փոխվել առանց որևէ մեկի խմբագրելու յուրաքանչյուր աշխատանքային ծանրաբեռնվածության երթուղին։ Հայտնաբերումը, երթուղու ընտրությունը և հավելվածի վերականգնումը ակնթարթային չեն և նույնը չեն տարբեր տեղակայումներում, ուստի փոխարկման թեստը պետք է դիտարկի ամբողջ հաջորդականությունը, ոչ թե առաջին անցնող փաթեթը։

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

Որտեղ են կոտրվում OSPF-ի ենթադրությունները

OSPF, IS-IS կամ այլ արձանագրություն IPsec թունելի ներսում լիովին հնարավոր է ինքնակառավարվող սարքում, որտեղ երկու ծայրերն ու փոխանցման դիզայնը ձերն են։ Այդ փաստը ոչինչ չի ասում կառավարվող ծառայության մասին, որը դինամիկ երթուղավորման ռեժիմով առաջարկում է միայն BGP։

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

Մի տեղափոխեք մեկ մատակարարի պատասխանը մյուսի դարպաս։ Նույն բառերը, օրինակ դինամիկ երթուղավորումը կամ թունելի փոխարկումը, կարող են նկարագրել տարբեր մեխանիզմներ և տարբեր սահմաններ։

Կարդացեք ծառայության պահանջը, ապա նախագծեք

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

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

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