Сайн уу, намайг Александр Азимов гэдэг. Yandex-д би янз бүрийн хяналтын систем, түүнчлэн тээврийн сүлжээний архитектурыг хөгжүүлдэг. Гэхдээ өнөөдөр бид BGP протоколын талаар ярих болно.
Долоо хоногийн өмнө Yandex нь ROV (Route Origin Validation)-ийг бүх түншүүд, мөн замын хөдөлгөөний солилцооны цэгүүдтэй холбох интерфейс дээр идэвхжүүлсэн. Үүнийг яагаад хийсэн, харилцаа холбооны операторуудтай харилцах харилцаанд хэрхэн нөлөөлөх талаар доороос уншина уу.
BGP ба энэ нь юу нь буруу вэ
BGP нь домайн хоорондын чиглүүлэлтийн протокол хэлбэрээр бүтээгдсэн гэдгийг та мэдэх байх. Гэсэн хэдий ч энэ замд ашиглалтын тохиолдлын тоо өссөөр байна: өнөөдөр BGP нь олон тооны өргөтгөлүүдийн ачаар VPN оператороос одоо моод болсон SD-WAN хүртэлх даалгавруудыг хамарсан мессежийн автобус болж, тэр ч байтугай программыг олсон байна. SDN-тэй төстэй хянагчдад зориулсан тээвэрлэлт нь BGP зайны векторыг холболтын протоколтой төстэй зүйл болгон хувиргадаг.
Зураг: арван тав.
BGP яагаад ийм олон хэрэглээг хүлээн авсан (мөн хүлээн авсаар байгаа) вэ? Хоёр үндсэн шалтгаан бий:
- BGP нь автономит систем (AS) хооронд ажилладаг цорын ганц протокол юм;
- BGP нь TLV (төрлийн урт-утга) форматын шинж чанаруудыг дэмждэг. Тийм ээ, энэ протокол нь ганцаараа биш, гэхдээ харилцаа холбооны операторуудын хоорондох уулзвар дээр үүнийг орлуулах зүйл байхгүй тул нэмэлт чиглүүлэлтийн протоколыг дэмжихээс илүү өөр функциональ элементийг хавсаргах нь үргэлж илүү ашигтай байдаг.
Түүнд ямар буруу байгаа юм бэ? Товчхондоо, протоколд хүлээн авсан мэдээллийн үнэн зөвийг шалгах механизм байдаггүй. Өөрөөр хэлбэл, BGP бол априори итгэлцлийн протокол юм: хэрэв та одоо Rostelecom, MTS эсвэл Yandex-ийн сүлжээг эзэмшдэг гэдгээ дэлхийд хэлэхийг хүсч байвал!
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) байна. Үндсэндээ энэ оруулга нь дараах зүйлийг харуулж байна: $ угтвар хаягийн орон зай эзэмшигч нь $max_length-ээс ихгүй урттай угтваруудыг сурталчлах AS дугаар $asn-д зөвшөөрөл өгсөн. Мөн RPKI кэшийг ашиглан чиглүүлэгчид хосыг нийцэж байгаа эсэхийг шалгах боломжтой угтвар - зам дээрх анхны яригч.
Зураг 3. RPKI архитектур
ROA объектууд нэлээд удаан хугацаанд стандартчилагдсан боловч саяхныг хүртэл IETF сэтгүүлд зөвхөн цаасан дээр үлдсэн байв. Миний бодлоор, үүний шалтгаан нь аймшигтай сонсогдож байна - муу маркетинг. Стандартчилал дууссаны дараа ROA нь BGP хулгайлахаас хамгаалсан нь үнэн биш юм. Халдагчид замын эхэнд зөв АС дугаар оруулснаар ROA-д суурилсан шүүлтүүрийг хялбархан тойрч гарах боломжтой. Энэхүү ухаарал гарч ирмэгц дараагийн логик алхам бол ROA-г ашиглахаас татгалзах явдал байв. Хэрэв энэ нь ажиллахгүй бол бидэнд яагаад технологи хэрэгтэй байна вэ?
Яагаад бодлоо өөрчлөх цаг болсон бэ? Учир нь энэ нь бүхэл бүтэн үнэн биш юм. ROA нь BGP дахь хакерын үйл ажиллагаанаас хамгаалдаггүй, гэхдээ санамсаргүйгээр замын хөдөлгөөнд оролцохоос хамгаална, жишээлбэл, улам бүр түгээмэл болж буй BGP дахь статик алдагдлаас. Түүнчлэн, IRR-д суурилсан шүүлтүүрүүдээс ялгаатай нь ROV-ийг зөвхөн үйлчлүүлэгчидтэй харилцах интерфейсээс гадна үе тэнгийнхэн болон дээд талын үйлчилгээ үзүүлэгчтэй харилцах интерфейст ашиглах боломжтой. Өөрөөр хэлбэл, RPKI-г нэвтрүүлэхтэй зэрэгцэн априори итгэл BGP-ээс аажмаар алга болж байна.
Одоо ROA дээр суурилсан маршрутыг шалгах ажлыг гол тоглогчид аажмаар хэрэгжүүлж байна: Европын хамгийн том IX нь буруу маршрутуудыг аль хэдийн хаясан; Tier-1 операторуудын дунд үе тэнгийн түншүүдтэйгээ интерфейс дээр шүүлтүүрийг идэвхжүүлсэн AT&T-ийг онцлон тэмдэглэх нь зүйтэй. Хамгийн том контент нийлүүлэгчид ч төсөлд ойртож байна. Мөн олон арван дунд оврын транзит операторууд энэ тухай хэнд ч хэлэлгүй чимээгүйхэн хэрэгжүүлчихсэн. Яагаад эдгээр бүх операторууд RPKI-г хэрэгжүүлж байна вэ? Хариулт нь энгийн: бусад хүмүүсийн алдаанаас таны гадагш урсгалыг хамгаалах. Тийм ч учраас Yandex нь ОХУ-д ROV-ийг сүлжээнийхээ захад оруулсан анхны хүмүүсийн нэг юм.
Дараа нь юу болох вэ?
Бид одоо замын хөдөлгөөний солилцооны цэгүүд болон хувийн peerings-ийн интерфейсүүд дээр чиглүүлэлтийн мэдээллийг шалгахыг идэвхжүүлсэн. Ойрын ирээдүйд дээд урсгалын урсгалын үйлчилгээ үзүүлэгчдээр баталгаажуулалтыг идэвхжүүлнэ.
Энэ нь таны хувьд ямар ялгаатай вэ? Хэрэв та өөрийн сүлжээ болон Yandex-ийн хоорондох траффикийн чиглүүлэлтийн аюулгүй байдлыг нэмэгдүүлэхийг хүсвэл бид дараахь зүйлийг санал болгож байна.
- Хаягийн талбарт гарын үсэг зурна уу - энэ нь энгийн, дунджаар 5-10 минут зарцуулдаг. Энэ нь хэн нэгэн таны хаягийн зайг санамсаргүйгээр хулгайлсан тохиолдолд бидний холболтыг хамгаалах болно (мөн энэ нь эрт орой хэзээ нэгэн цагт тохиолдох болно);
- Нээлттэй эхийн RPKI кэшүүдийн аль нэгийг суулгана уу (, ) болон сүлжээний хил дээр чиглүүлэлтийн шалгалтыг идэвхжүүлэх - энэ нь илүү их цаг хугацаа шаардагдах боловч дахин хэлэхэд энэ нь техникийн ямар ч хүндрэл учруулахгүй.
Yandex нь шинэ RPKI объект дээр суурилсан шүүлтүүрийн системийг хөгжүүлэхийг дэмждэг. (Автоном систем нийлүүлэгчийн зөвшөөрөл). ASPA болон ROA объектууд дээр суурилсан шүүлтүүрүүд нь зөвхөн "нэвчсэн" AS-SET-ийг орлуулахаас гадна BGP ашиглан MiTM халдлагын асуудлыг хааж болно.
Би сарын дараа Next Hop чуулган дээр ASPA-ийн талаар дэлгэрэнгүй ярих болно. Netflix, Facebook, Dropbox, Juniper, Mellanox, Yandex-ийн хамт олон тэнд үг хэлэх болно. Цаашид сүлжээний стек болон түүний хөгжүүлэлтийн талаар сонирхож байвал ирээрэй .
Эх сурвалж: www.habr.com