Բարև, ես Ալեքսանդր Ազիմովն եմ: Yandex-ում ես մշակում եմ մոնիտորինգի տարբեր համակարգեր, ինչպես նաև տրանսպորտային ցանցի ճարտարապետություն: Բայց այսօր մենք կխոսենք BGP արձանագրության մասին:
Մեկ շաբաթ առաջ Yandex-ը միացրել է ROV-ը (Route Origin Validation) բոլոր գործընկերների հետ ինտերֆեյսներում, ինչպես նաև երթևեկության փոխանակման կետերում: Ստորև կարդացեք, թե ինչու դա արվեց և ինչպես դա կազդի հեռահաղորդակցության օպերատորների հետ փոխգործակցության վրա:
BGP-ն և ինչն է դրա սխալը
Դուք հավանաբար գիտեք, որ BGP-ն նախագծվել է որպես միջդոմենային երթուղային արձանագրություն: Այնուամենայնիվ, ճանապարհին, օգտագործման դեպքերի թիվը հասցրեց աճել. այսօր BGP-ն, բազմաթիվ ընդարձակումների շնորհիվ, վերածվել է հաղորդագրությունների ավտոբուսի, որը ծածկում է առաջադրանքները VPN օպերատորից մինչև այժմ մոդայիկ SD-WAN և նույնիսկ գտել է կիրառություն որպես տրանսպորտ SDN-ի նման կարգավորիչի համար, որը հեռավորության վեկտորը BGP-ն վերածում է հղումների նստած արձանագրության նման մի բանի:
Բրինձ 1
Ինչո՞ւ է BGP-ն ստացել (և շարունակում է ստանալ) այդքան շատ օգտագործում: Երկու հիմնական պատճառ կա.
- BGP-ն միակ արձանագրությունն է, որն աշխատում է ինքնավար համակարգերի (AS) միջև;
- BGP-ն աջակցում է ատրիբուտներին TLV (տեսակ-երկարություն-արժեք) ձևաչափով: Այո, արձանագրությունը միայնակ չէ դրանում, բայց քանի որ այն փոխարինելու ոչինչ չկա հեռահաղորդակցության օպերատորների միջև հանգույցներում, միշտ պարզվում է, որ ավելի ձեռնտու է դրան կցել մեկ այլ ֆունկցիոնալ տարր, քան օժանդակել լրացուցիչ երթուղային արձանագրությանը:
Ի՞նչ է նրա հետ: Մի խոսքով, արձանագրությունը չունի ներկառուցված մեխանիզմներ՝ ստուգելու ստացված տեղեկատվության ճիշտությունը։ Այսինքն, BGP-ն ապրիորի վստահության արձանագրություն է. եթե ուզում եք աշխարհին ասել, որ այժմ պատկանում եք Ռոստելեկոմի, ՄՏՍ-ի կամ Յանդեքսի ցանցին, խնդրում եմ:
IRRDB-ի վրա հիմնված զտիչ՝ վատագույններից լավագույնը
Հարց է առաջանում՝ ինչո՞ւ է ինտերնետը դեռ աշխատում նման իրավիճակում։ Այո, այն աշխատում է շատ ժամանակ, բայց միաժամանակ պարբերաբար պայթում է՝ անհասանելի դարձնելով ամբողջ ազգային հատվածներ։ Չնայած BGP-ում հաքերների գործունեությունը նույնպես աճում է, անոմալիաների մեծ մասը դեռևս առաջանում է սխալների պատճառով: Այս տարվա օրինակն է Բելառուսում, ինչը կես ժամով անհասանելի դարձրեց համացանցի զգալի մասը MegaFon-ի օգտատերերի համար։ Մեկ այլ օրինակ - կոտրել է աշխարհի ամենամեծ CDN ցանցերից մեկը:
Բրինձ. 2. Cloudflare երթևեկության խափանում
Բայց, այնուամենայնիվ, ինչո՞ւ են նման անոմալիաներ լինում վեց ամիսը մեկ, այլ ոչ ամեն օր։ Քանի որ օպերատորներն օգտագործում են երթուղային տեղեկատվության արտաքին տվյալների բազաները՝ ստուգելու, թե ինչ են ստանում BGP-ի հարևաններից: Նման տվյալների բազաները շատ են, դրանցից մի քանիսը կառավարվում են գրանցողների կողմից (RIPE, APNIC, ARIN, AFRINIC), ոմանք անկախ խաղացողներ են (ամենահայտնին RADB-ն է), և կա նաև խոշոր ընկերություններին պատկանող ռեգիստրների մի ամբողջ շարք (Level3): , NTT և այլն): Այս տվյալների բազաների շնորհիվ է, որ միջդոմենային երթուղավորումը պահպանում է իր գործունեության հարաբերական կայունությունը:
Այնուամենայնիվ, կան նրբերանգներ. Երթուղային տեղեկատվությունը ստուգվում է ROUTE-OBJECTS և AS-SET օբյեկտների հիման վրա: Եվ եթե առաջինը թույլտվություն է ենթադրում IRRDB-ի մի մասի համար, ապա երկրորդ դասի համար որպես դասի թույլտվություն չկա: Այսինքն՝ յուրաքանչյուրը կարող է որևէ մեկին ավելացնել իր հավաքածուներին և դրանով իսկ շրջանցել հոսանքով ընթացող մատակարարների ֆիլտրերը։ Ավելին, տարբեր IRR բազաների միջև AS-SET անվանման եզակիությունը երաշխավորված չէ, ինչը կարող է հանգեցնել զարմանալի հետևանքների՝ կապի հանկարծակի կորստով հեռահաղորդակցության օպերատորի համար, որն իր հերթին ոչինչ չի փոխել:
Լրացուցիչ մարտահրավեր է AS-SET-ի օգտագործման օրինակը: Այստեղ երկու կետ կա.
- Երբ օպերատորը ստանում է նոր հաճախորդ, այն ավելացնում է իր AS-SET-ում, բայց գրեթե երբեք չի հեռացնում այն;
- Զտիչներն իրենք կազմաձևված են միայն հաճախորդների հետ ինտերֆեյսներում:
Արդյունքում, BGP ֆիլտրերի ժամանակակից ձևաչափը բաղկացած է աստիճանաբար նվաստացնող զտիչներից հաճախորդների հետ ինտերֆեյսներում և ապրիորի վստահությունից այն ամենի նկատմամբ, ինչ գալիս է գործընկերների և IP տարանցման մատակարարներից:
Ի՞նչ է փոխարինում AS-SET-ի վրա հիմնված նախածանցային զտիչները: Ամենահետաքրքիրն այն է, որ կարճաժամկետ կտրվածքով՝ ոչինչ։ Բայց ի հայտ են գալիս լրացուցիչ մեխանիզմներ, որոնք լրացնում են IRRDB-ի վրա հիմնված ֆիլտրերի աշխատանքը, և առաջին հերթին սա, իհարկե, RPKI-ն է։
RPKI
Պարզեցված ձևով RPKI ճարտարապետությունը կարելի է դիտարկել որպես բաշխված տվյալների բազա, որի գրառումները կարող են գաղտնագրորեն ստուգվել: ROA-ի (Route Object Authorization) դեպքում ստորագրողը հասցեական տարածքի սեփականատերն է, իսկ գրառումն ինքնին եռապատիկ է (նախածանց, asn, max_length): Ըստ էության, այս գրառումը ենթադրում է հետևյալը. $prefix հասցեների տարածության սեփականատերը լիազորել է $asn ՀԾ համարը գովազդելու $max_length-ից ոչ ավելի երկարությամբ նախածանցներ: Եվ երթուղիչները, օգտագործելով RPKI քեշը, կարողանում են ստուգել զույգի համապատասխանությունը նախածանց - առաջին խոսնակը ճանապարհին.
Նկար 3. RPKI ճարտարապետություն
ROA օբյեկտները բավականին երկար ժամանակ ստանդարտացված էին, բայց մինչև վերջերս դրանք իրականում մնում էին միայն թղթի վրա IETF ամսագրում: Իմ կարծիքով, դրա պատճառը սարսափելի է հնչում` վատ մարքեթինգ: Ստանդարտացման ավարտից հետո խթանն այն էր, որ ROA-ն պաշտպանում էր BGP-ի առևանգումից, ինչը ճիշտ չէր: Հարձակվողները կարող են հեշտությամբ շրջանցել ROA-ի վրա հիմնված զտիչները՝ ճանապարհի սկզբում տեղադրելով ճիշտ AC համարը: Եվ հենց այս գիտակցումը եկավ, հաջորդ տրամաբանական քայլը ROA-ի օգտագործումից հրաժարվելն էր։ Եվ իսկապես, ինչո՞ւ է մեզ անհրաժեշտ տեխնոլոգիան, եթե այն չի աշխատում:
Ինչու է ժամանակն է փոխել ձեր միտքը: Քանի որ սա ամբողջ ճշմարտությունը չէ։ ROA-ն չի պաշտպանում BGP-ում հաքերային գործունեությունից, բայց պաշտպանում է պատահական երթևեկության առևանգումից, օրինակ BGP-ում ստատիկ արտահոսքից, որն ավելի ու ավելի տարածված է դառնում: Բացի այդ, ի տարբերություն IRR-ի վրա հիմնված ֆիլտրերի, ROV-ը կարող է օգտագործվել ոչ միայն հաճախորդների հետ ինտերֆեյսներում, այլև հասակակիցների և հոսանքին հակառակ մատակարարների ինտերֆեյսներում: Այսինքն՝ RPKI-ի ներդրմանը զուգահեռ BGP-ից աստիճանաբար վերանում է a priori վստահությունը։
Այժմ ROA-ի վրա հիմնված երթուղիների ստուգումն աստիճանաբար իրականացվում է հիմնական խաղացողների կողմից. խոշորագույն եվրոպական IX-ն արդեն հրաժարվում է սխալ երթուղիներից, Tier-1 օպերատորների շարքում արժե առանձնացնել AT&T-ն, որն իր գործընկեր գործընկերների հետ ինտերֆեյսներում միացրել է զտիչներ: Նախագծին են մոտենում նաև բովանդակության ամենամեծ մատակարարները: Իսկ միջին տրանզիտային տասնյակ օպերատորներ արդեն հանգիստ իրականացրել են դա՝ ոչ մեկին չասելով այդ մասին։ Ինչո՞ւ են այս բոլոր օպերատորներն իրականացնում RPKI: Պատասխանը պարզ է՝ պաշտպանել ձեր ելքային տրաֆիկը այլ մարդկանց սխալներից: Այդ իսկ պատճառով Yandex-ը Ռուսաստանի Դաշնությունում առաջիններից է, որն իր ցանցի եզրին է ներառել ROV-ը:
Ինչ է լինելու հաջորդը.
Այժմ մենք հնարավորություն ենք տվել ստուգել երթուղային տեղեկատվությունը երթևեկության փոխանակման կետերի և մասնավոր peerings-ի միջերեսներում: Մոտ ապագայում ստուգումը կակտիվացվի նաև վերին հոսքի երթևեկության մատակարարների հետ:
Ի՞նչ տարբերություն սա ձեզ համար: Եթե ցանկանում եք բարձրացնել երթևեկության անվտանգությունը ձեր ցանցի և Yandex-ի միջև, խորհուրդ ենք տալիս.
- Ստորագրեք ձեր հասցեի տարածքը - պարզ է, միջինը տևում է 5-10 րոպե: Սա կպաշտպանի մեր կապը այն դեպքում, երբ ինչ-որ մեկը ակամա գողանա ձեր հասցեի տարածքը (և դա անպայման տեղի կունենա վաղ թե ուշ);
- Տեղադրեք բաց կոդով RPKI քեշերից մեկը (, ) և միացրեք երթուղու ստուգումը ցանցի սահմանին. դա ավելի շատ ժամանակ կպահանջի, բայց նորից տեխնիկական դժվարություններ չի առաջացնի:
Yandex-ը նաև աջակցում է զտիչ համակարգի մշակմանը, որը հիմնված է նոր RPKI օբյեկտի վրա. (Ինքնավար համակարգի մատակարարի թույլտվություն): ASPA և ROA օբյեկտների վրա հիմնված զտիչները կարող են ոչ միայն փոխարինել «արտահոսող» AS-SET-ներին, այլև փակել MiTM հարձակումների խնդիրները՝ օգտագործելով BGP:
ASPA-ի մասին մանրամասն կխոսեմ մեկ ամսից՝ Next Hop կոնֆերանսում։ Այնտեղ կխոսեն նաև Netflix-ի, Facebook-ի, Dropbox-ի, Juniper-ի, Mellanox-ի և Yandex-ի գործընկերները։ Եթե դուք հետաքրքրված եք ցանցային ստեկով և ապագայում դրա զարգացմամբ, եկեք .
Source: www.habr.com