Една од најголемите друштвени мрежи во светот, Facebook, заедно со добар дел од своите платформи, но и интерни системи оваа недела на неколку часа останаа целосно недостапни за своите вработени и корисници. Покрај Instagram и WhatsApp, глобално недостапни беа и куп интерни сервиси кои ги користат вработените во Facebook, од алатки за комуникација како имејл, до системите за отклучување на вратите.
Причина за овој ИТ кошмар овој пат беше погрешно сетирање на Border Gateway протоколот на компанијата, кој всушност е протокол задолжен за „цртање“ на мапа од една до друга точка од интернет инфраструктурата. Facebook и останатите сервиси се вратени и функционираат, но која беше причината за недостапноста?
Што е BGP
Cloudflare го опишува Border Gateway Protocol како „интернет пошта“. Кога некој пакет доаѓа во пошта, поштата треба да одбере најефикасна патека како да го испрати пакетот до примачот. Истото важи за Border Gate протоколот, тој всушност помага да се одбере оптималната рута за податоците на Интернет да стигнат од една до друга локација.
Она што го овозможува BGP е рутирањето на податоците помеѓу различни автономни системи (AS) на интернет. Кога ќе одберете да ја посетите https://facebook.com, овој протокол овозможува врската помеѓу корисник од Македонија со податочните центри лоцирани во Данска, Ирска или Шведска да биде брза и ефикасна. Автономни системи се помали мрежи со чие спојување се креира големата интернет мрежа. Во смисол на претходната аналогија овие автономни системи би биле градски пошти. Без разлика каде во градот пратката треба да стигне, пред да биде испорачана мора да помине низ главната пошта. Потоа внатре во автономните системи сообраќајот се рутира по внатрешни патеки. Овие системи се индивидуални мрежи со внатрешна политика за рутирање до крајните точки.
Автономните системи се идентификуваат преку единствен идентификатор – Autonomous System Number (ASN). Идентификаторот секогаш започнува со „AS“ по што следи низа од бројки. На пример ASN на Google е AS15169; ASN на Facebook е AS32934; ASN на Cloudflare e АS13335.
Како се креира патека помеѓу два автономни системи
Примерот искористен на Cloudflare има шест автономни системи поврзани во мрежа. Пакет се испраќа од AS1 на AS3. За пакетот да стигне до посакуваната дестинација има две патеки. Почетната и крајната патека секако во двата случаи се исти. Првата патека е од AS1 преку AS2 до AS3. Втората е преку AS6, AS5, AS4 до AS3. Секако во случајов посакувана е првата рута која во дадениот пример е пократка и поефикасна.
Ова е прилично едноставен систем кој не постои во реалноста. Во реалноста во изборот на рутата влегуваат многу повеќе автономни системи. Иако бројот на автономни системи во патеката е еден показател, вистински рутирањата имаат повеќе параметри по кои се одбира најдобрата патека. На пример како параметри за избор на патека може да бидат различна цена за сообраќај по различни патеки. Очекувано, овие патеки се менуваат, па BGP треба да ги има актуелните листи за да може да одбере патека која постои. За секоја промена на BGP до рутерите пристига BGP UPDATE порака која во која се содржани новите информации за префиксите.
Што се случи со Facebook?
Во случајот на Facebook не е до крај објаснето како точно дојде до проблемот… Компанијата имаше кратко објаснување на својата страница, но без фокус на што точно е причина за проблемите. Се надеваме дека наскоро ќе има и подетални информации за настанот.
„Нашиот тим на инженери откри дека промени во конфигурацијата на бекбоун рутерите кој го координираат мрежниот сообраќај помеѓу податочните центри предизвика проблеми кои ја нарушија оваа комуникација. Ова нарушување има каскаден ефект во начинот на кој комуницираат нашите податочни центри, што ги запре нашите сервиси.
Сега сите сервиси се повторно активни и работиме да ги вратиме во регуларна работа. Сакаме да бидеме потполно јасни, во моментов веруваме дека причина за прекинот е погрешна промена на конфигурацијата. Нема доказ дека податоците на корисниците се компромитирани како резултат на овој прекин.“, вели Сантош Јанардхан, заменик директор во Facebook одделот за инфраструктура.
Засега непотврдени податоци велат дека сè започна со операција која требала да биде рутинска надградба на BGP.
Слични податоци сподели и Cloudflare кој го лоцираше почетокот на проблемите со голема промена на BGP на Facebook. Промената во најголем дел опфаќаше повлекување на постоечки патеки. Една минута по повлекувањето на рутите, DNS серверите „отидоа офлајн“. Речиси веднаш и DNS резолверите (DNS Resolver) престанаа да ги пронаоѓаат имињата на нивните домени. Ова се случи затоа што DNS како и многу останати системи на Интернет има механизам за рутирање. Кога некој ќе ја напише адресата во полето на прелистувачот, DNS резолверот (DNS resolver) кој треба да го преведе името во IP-адреса, најпрво проверува дали има нешто искеширано и го користи ова. Ако нема, се обидува да добие одговор од домејн нејмсерверот (nameserver).
Истовремено грешките на Facebook влијаеа и на остатокот на интернет. Поради големината на Facebook, апликациите кои не овозможуваат грешка како DNS одговор, и корисниците кои притискаат „refresh“, DNS резолверите добиваа над 30 повици повеќе од вообичаено. Ова предизвика доцнење и timeout и на други платформи кои во овој момент немаа проблем.
Во моментот кога беа направени BGP промените, сајтот беше „избришан“ од интернет мапата и потребно беше повторно да се вратат назад постоечките рути, но ова не е едноставно…
„Сепак, ова е полесно да се каже отколку да се направи. Пристигаа извештаи дека вработените на Facebook се заклучени зад врати заштитени со беџ; дека имаат пречки во комуникацијата. Во вакви ситуации, не само што треба да знаете кој има знаење, а кој има пермисии да го реши проблемот, туку треба да најдете и начин како да ги поврзете овие луѓе. Кога целата компанија е потоната, тоа не е лесна задача. The Verge дојде до извештаи за инженери кои се физички испратени до центарот за податоци на Фејсбук во Калифорнија за да се обидат да го поправат проблемот“.
Конечно се чини дека оваа група на инженери за која зборува Verge успеа да ја отстрани грешката и да ги врати системите назад.
Како BGP креираше еднодневна криза
Ова не е првпат грешки поврзани со BGP да креираат сериозни нарушувања во интернет сообраќајот. Во 2004 турскиот интернет провајдер TTNet сподели лоши рути во кој се „самопрогласи“ за најдобра дестинација за целиот интернет сообраќај. Овие рути се проширија до повеќе автономни системи, кои потоа придонесоа многу луѓе да останат без пристап до интернет.
Во 2008 година Пакистан се обиде да ги спречи пристапот до YouTube за своите граѓани. Пакистанскиот интернет провајдер ги апдејтираше рутите и по грешка ги сподели со соседните автономни системи. Како последица цел сообраќај до YouTube водеше до празна страница, а YouTube остана недостапен неколку часа.
„Вакви инциденти може да се случат бидејќи функцијата за споделување рути на BGP e заснована на доверба, а автономните системи имплицитно им веруваат на рутите што се споделуваат со нив. Иако има повеќе амбициозни предлози наменети да го направат BGP посигурен, тие се тешки за имплементација, бидејќи ќе бараат од секој автономен систем истовремено да го ажурира своето однесување. Ова подразбира координација на стотици илјади организации, и потенцијално би резултирало со привремена пауза на целиот Интернет, па се чини малку веројатно дека некој од овие предлози ќе биде наскоро имплементиран“, објаснуваат од Cloudflare.