Саламатсыздарбы, менин атым Александр Азимов. Яндекс, мен ар кандай мониторинг системаларын, ошондой эле транспорт тармагынын архитектурасын иштеп чыгуу. Бирок бүгүн биз BGP протоколу жөнүндө сүйлөшөбүз.
Бир жума мурун Яндекс бардык өнөктөш өнөктөштөр, ошондой эле трафик алмашуу пункттары менен интерфейстерде ROV (Route Origin Validation) функциясын иштеткен. Бул эмне үчүн жасалгандыгы жана ал байланыш операторлору менен өз ара аракеттенүүгө кандай таасир этээри жөнүндө төмөндө оку.
BGP жана анда эмне туура эмес
Сиз BGP домен аралык каттам протоколу катары иштелип чыкканын билесиз. Бирок, бул жол менен, колдонуу учурларынын саны өсө алды: бүгүнкү күндө BGP, көптөгөн кеңейтүүлөрдүн аркасында, VPN операторунан азыркы модалуу SD-WANга чейинки тапшырмаларды камтыган билдирүү автобусуна айланды жана ал тургай тиркемени дагы тапты. SDN сымал контроллер үчүн транспорт, BGP аралык векторун шилтемелер сат протоколуна окшош нерсеге айландырат.
Figure: 1.
Эмне үчүн BGP мынчалык көп колдонууну алды (жана алууну улантууда)? Мунун эки негизги себеби бар:
- BGP автономдуу системалардын (AS) ортосунда иштеген жалгыз протокол;
- BGP TLV (түр узундугу-маани) форматындагы атрибуттарды колдойт. Ооба, бул жерде протокол жалгыз эмес, бирок байланыш операторлорунун ортосундагы түйүндөрдө аны алмаштыруучу эч нерсе болбогондуктан, кошумча маршруттук протоколду колдоого караганда ага башка функционалдык элементти тиркөө дайыма пайдалуураак болуп чыгат.
Ага эмне болду? Кыскасы, протоколдо алынган маалыматтын тууралыгын текшерүү үчүн орнотулган механизмдер жок. Башкача айтканда, BGP - бул априори ишеним протоколу: эгер сиз дүйнөгө азыр Ростелеком, МТС же Яндекс тармагынын ээси экениңизди айткыңыз келсе, сураныч!
IRRDB негизиндеги чыпка - эң жамандын эң жакшысы
Суроо туулат: эмне үчүн Интернет дагы деле ушундай кырдаалда иштейт? Ооба, ал көпчүлүк учурда иштейт, бирок ошол эле учурда ал мезгил-мезгили менен жарылып, бүтүндөй улуттук сегменттерге жеткиликсиз кылып турат. BGPде хакерлердин активдүүлүгү да өсүп жатканына карабастан, аномалиялардын көбү дагы эле мүчүлүштүктөрдөн улам келип чыгат. Быйылкы мисал Беларуста интернеттин олуттуу бөлүгүн MegaFon колдонуучулары жарым саатка жеткиликсиз кылып койду. Башка мисал - дүйнөдөгү эң чоң CDN тармактарынын бирин талкалады.
Райс. 2. Cloudflare трафикти токтотуу
Ошентсе да, эмне үчүн мындай аномалиялар күн сайын эмес, жарым жылда бир жолу болуп турат? Анткени ташуучулар BGP кошуналарынан алганын текшерүү үчүн маршруттук маалыматтын тышкы базаларын колдонушат. Мындай маалымат базалары көп, алардын айрымдары регистрлер тарабынан башкарылат (RIPE, APNIC, ARIN, AFRINIC), кээ бирлери көз карандысыз оюнчулар (эң атактуусу RADB), ошондой эле ири компанияларга таандык регистрлердин бүтүндөй топтому бар (3-деңгээл). , 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 дарек мейкиндигинин ээси AS номерине $asn узундугу $max_length ашпаган префикстерди жарнамалоого уруксат берген. Ал эми роутерлор RPKI кэшин колдонуп, жуптун шайкештигин текшере алышат префикс - жолдо биринчи сүйлөгөн.
Сүрөт 3. RPKI архитектурасы
ROA объектилери бир топ убакыттан бери стандартташтырылган, бирок жакында эле алар IETF журналында кагаз жүзүндө гана калган. Менин оюмча, мунун себеби коркунучтуу угулат - жаман маркетинг. Стандартташтыруу аяктагандан кийин, ROA BGP уурдоосунан коргогон стимул болду - бул туура эмес. Чабуулчулар жолдун башына туура AC номерин киргизүү менен ROA негизиндеги чыпкаларды оңой эле айланып өтүшөт. Жана бул ишке ашар замат, кийинки логикалык кадам ROA колдонуудан баш тартуу болду. Жана чындап эле, эгер ал иштебесе, бизге эмне үчүн технология керек?
Эмне үчүн оюңду өзгөртүүгө убакыт келди? Анткени бул бүтүндөй чындык эмес. ROA BGPдеги хакерлердин активдүүлүгүнөн коргобойт, бирок кокусунан унаа уурдоодон коргойт, мисалы, кеңири таралган BGPдеги статикалык агып кетүүдөн. Ошондой эле, IRR негизиндеги чыпкалардан айырмаланып, ROV кардарлар менен болгон интерфейстерде гана эмес, теңтуштар жана жогорку провайдерлер менен интерфейстерде да колдонулушу мүмкүн. Башкача айтканда, RPKI киргизүү менен бирге, априори ишеним BGPден акырындык менен жок болууда.
Эми, ROAга негизделген маршруттарды текшерүү акырындык менен негизги оюнчулар тарабынан ишке ашырылууда: эң чоң европалык IX Tier-1 операторлорунун арасында туура эмес маршруттарды жокко чыгарып жатат, анын теңдеш өнөктөштөрү менен интерфейстеринде чыпкаларды иштеткен AT&Tди баса белгилеп кетүү керек; Ири контент провайдерлери да долбоорго жакындашууда. Ал эми ондогон орто транзиттик операторлор бул тууралуу эч кимге айтпай, унчукпай ишке ашырышты. Эмне үчүн бул операторлордун бардыгы RPKIди ишке ашырып жатышат? Жооп жөнөкөй: башка адамдардын каталарынан сиздин чыгуучу трафикти коргоо. Ошондуктан Яндекс Россия Федерациясында биринчилерден болуп ROV тармагын өз тармагынын четине киргизген.
Эми эмне болот?
Биз азыр трафик алмашуу пункттары жана жеке пирингдер менен интерфейстерде маршруттук маалыматты текшерүүнү иштеттик. Жакынкы келечекте текшерүү жогорку агымдагы трафик провайдерлери менен да иштетилет.
Мунун сиз үчүн кандай айырмасы бар? Тармагыңыз менен Яндекстин ортосундагы трафиктин коопсуздугун жогорулатууну кааласаңыз, биз төмөнкүлөрдү сунуштайбыз:
- Дарек мейкиндигине кол коюңуз - бул жөнөкөй, орточо 5-10 мүнөт талап кылынат. Бул кимдир бирөө байкабастан сиздин дарек мейкиндигин уурдап кеткен учурда биздин байланышты коргойт (жана бул сөзсүз түрдө эртеби-кечпи болот);
- Ачык булактуу RPKI кэштеринин бирин орнотуңуз (, ) жана тармак чектеринде маршрутту текшерүүнү иштетиңиз - бул көбүрөөк убакытты талап кылат, бирок дагы бир жолу, эч кандай техникалык кыйынчылыктарды жаратпайт.
Яндекс жаңы RPKI объектинин негизинде чыпкалоо системасын иштеп чыгууну да колдойт - (Автономдук системанын провайдеринин авторизациясы). ASPA жана ROA объектилерине негизделген чыпкалар "аккан" AS-SETтерди гана алмаштырбастан, BGP аркылуу MiTM чабуулдарынын маселелерин да жаба алат.
Мен бир айдан кийин Next Hop конференциясында ASPA жөнүндө кеңири айтып берем. Ал жерде Netflix, Facebook, Dropbox, Juniper, Mellanox жана Яндекстин кесиптештери да сөз сүйлөшөт. Эгерде сизди тармактык стек жана келечекте анын өнүгүшү кызыктырса, келиңиз .
Source: www.habr.com