Сәлем, менің атым Александр Азимов. Яндекс-те мен әртүрлі бақылау жүйелерін, сондай-ақ көлік желісінің архитектурасын әзірлеймін. Бірақ бүгін біз BGP хаттамасы туралы айтатын боламыз.
Бір апта бұрын Яндекс барлық серіктес серіктестермен интерфейстерде, сондай-ақ трафик алмасу нүктелерінде 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), сонымен қатар ірі компанияларға тиесілі тіркеушілердің тұтас жиынтығы бар (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 мекенжай кеңістігінің иесі ұзындығы $max_length-тен аспайтын префикстерді жарнамалау үшін $asn AS нөміріне рұқсат берді. Ал маршрутизаторлар RPKI кэшін пайдалана отырып, жұптың сәйкестігін тексере алады префикс - жолда бірінші сөйлеуші.
Сурет 3. RPKI архитектурасы
ROA объектілері ұзақ уақыт бойы стандартталған, бірақ соңғы уақытқа дейін олар IETF журналында тек қағаз жүзінде қалды. Менің ойымша, мұның себебі қорқынышты естіледі - нашар маркетинг. Стандарттау аяқталғаннан кейін ROA BGP ұрлаудан қорғады деген ынталандыру болды - бұл дұрыс емес. Шабуылшылар жолдың басына дұрыс айнымалы ток нөмірін енгізу арқылы 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 және Yandex әріптестері де сөз сөйлейді. Егер сізді болашақта желілік стек және оның дамуы қызықтырса, келіңіз .
Ақпарат көзі: www.habr.com