Спадзьвіг мяне на гэтую пасаду .
Прыводжу яго тут:
сёння ў 18:53
Мяне сёння парадаваў правайдэр. Разам з абнаўленнем сістэмы блакавання сайтаў, у яго пад бан трапіў паштар mail.ru З раніцы тузаю тэхпадтрымку, нічога зрабіць не могуць. Правайдэр маленькі, і блакуюць мабыць вышэйстаячыя правайдэры. Яшчэ заўважыў запаволенне адкрыццё ўсіх сайтаў, можа нейкае крывое DLP навесілі? Раней ніякіх праблем з доступам не было. Знішчэнне рунэту ідзе прама на маіх вачах…
Справа ў тым, што, здаецца, мы і ёсць той самы правайдэр 🙁
І сапраўды, амаль угадаў з прычынай праблем з mail.ru (хоць мы доўга адмаўляліся верыць у падобнае).
Далейшае будзе падзелена на дзве часткі:
- прычыны нашых сённяшніх праблем з mail.ru і займальны квэст па іх пошуку
- існаванне ISP у сённяшніх рэаліях, стабільнасць суверэннага рунэту.
Праблемы з даступнасцю mail.ru
Ох, гэта даволі доўгая гісторыя.
Справа ў тым, што для рэалізацыі патрабаванняў дзяржавы (падрабязней у другой частцы) намі было набыта, настроена, устаноўлена некаторае абсталяванне - як для фільтрацыі забароненых рэсурсаў, так і для ажыццяўлення абанентаў.
Некаторы час таму мы нарэшце перабудавалі ядро сеткі такім чынам, каб увесь трафік абанентаў праходзіў праз гэтае абсталяванне строга ў патрэбным кірунку.
Некалькі дзён таму ўключылі на ім фільтраванне забароны (адначасова пакінуўшы працаваць і старую сістэму) – з выгляду ўсё прайшло добра.
Далей – паступова сталі ўключаць для розных частак абанентаў NAT на гэтым абсталяванні. З выгляду - таксама ўсё, быццам бы, пайшло нядрэнна.
Але сёння, уключыўшы на абсталяванні NAT для чарговай часткі абанентаў - з самай раніцы сутыкнуліся з прыстойнай колькасцю скаргаў аб недаступнасці або частковай даступнасці і іншых рэсурсаў Mail Ru Group.
Пачалі правяраць: нешта недзе часам, зрэдку шлёт у адказ на запыты выключна да сетак mail.ru. Больш за тое – шле няслушна згенераваны (без ACK), відавочна штучны TCP RST. Прыкладна так гэта выглядала:
Натуральна, першыя думкі былі аб новым абсталяванні: страшны DPI, даверу да яго ніякага, ці мала што ён можа ўчуць – бо TCP RST – гэта даволі распаўсюджаная штука сярод сродкаў блакіровак.
здагадка аб тым, што фільтруе хтосьці «вышэйстаячы», мы таксама вылучылі – але тут жа адкінулі.
Па-першае, у нас дастаткова разумныя аплінкі, каб падобным не пакутаваць 🙂
Па-другое, мы падключаны да некалькіх у Маскве, і трафік да mail.ru ідзе менавіта праз іх – а ўжо ў іх няма ні абавязкаў, ні якога-небудзь іншага матыву фільтраваць трафік.
Наступная палова дня была выдаткавана на тое, што звычайна называюць шаманствам - разам з вендарам абсталявання, за што ім дзякуй, не кінулі 🙂
- цалкам адключалася фільтраванне
- адключаўся NAT па новай схеме
- тэставы ПК выносіўся ў асобны ізаляваны пул
- мянялася IP-адрасацыя
У другой палове дня была выдзелена віртуалка, якая выходзіць у сетку па схеме звычайнага карыстальніка, і да яе і да абсталявання быў дадзены доступ прадстаўнікам вендара. Шаманства працягвалася 🙂
У рэшце рэшт прадстаўнік вендара ўпэўнена заявіў, што жалязяка дакладна ні пры чым: rst`ы прыходзяць аднекуль вышэй.
ЗаўвагаУ гэтым месцы хтосьці можа заявіць: але ж значна прасцей было зняць дамп не з тэставага ПК, а з магістралі вышэй за DPI?
Не, нажаль, зняць дамп (і нават проста адмірарыць) 40+gbps зусім не трывіяльна.
Пасля гэтага, ужо ўвечары - не заставалася нічога іншага, як вярнуцца да здагадкі аб дзіўнай фільтрацыі дзесьці вышэй.
Я паглядзеў, праз які IX зараз ходзіць трафік да сетак МРГ і проста пагасіў да яго bgp-сесіі. І - о цуд! - усё неадкладна нармалізавалася 🙁
З аднаго боку - вельмі шкада, што на пошук праблемы быў выдаткаваны ўвесь дзень, хоць вырашалася яна за пяць хвілін.
З другога боку:
- На маёй памяці гэта беспрэцэдэнтная штука. Як я ўжо пісаў вышэй - IX `ам сапраўды няма ніякага сэнсу фільтраваць транзітны трафік. У іх яго звычайна сотні гігабіт / тэрабіты ў секунду. Я проста да апошняга не мог усур'ёз падобнага выказаць здагадку.
- неверагодна ўдалы збег абставінаў: новае складанае жалеза, якому няма асаблівага даверу і ад якога незразумела, чаго можна чакаць - заменчанае як раз пад блакіроўку рэсурсаў, у тым ліку TCP RST`амі
У сапраўдны момант NOC гэтага internet exchange шукае праблему. Па іх сцвярджэнні (і я ім веру) ніякай спецыяльна разгорнутай сістэмы фільтрацыі ў іх няма. Але, падзяка небу, далейшы квэст - ужо не наша праблема 🙂
Гэта была невялікая спроба апраўдацца, просім зразумець і прабачыць 🙂
PS: я наўмысна не заву ні вытворцы DPI/NAT, ні IX (у мяне, уласна, нават няма да іх адмысловых прэтэнзій, галоўнае – зразумець, што гэта было)
Сённяшняя (а таксама ўчорашняя і пазаўчарашняя) рэальнасць з пункту гледжання інтэрнэт-правайдэра
Апошнія тыдні я правёў, значна перабудоўваючы ядро сеткі, вырабляючы кучу маніпуляцый "нажывую", з рызыкай значна закрануць жывы карыстацкі трафік. Улічваючы мэты, вынікі і наступствы ўсяго гэтага - маральна ўсё гэта досыць цяжка. Асабліва - у чарговы раз слухаючы прыгожыя прамовы аб абароне стабільнасці рунэту, суверэнітэце, і г.д. і да т.п.
У гэтым раздзеле я паспрабую расказаць "эвалюцыю" ядра сеткі тыповага інтэрнэт-правайдэра за апошні дзясятак гадоў.
Дзесятак гадоў таму.
У тыя блаславёныя часы ядро правайдэрскай сеткі магло быць простым і надзейным, як корак:
На гэтай вельмі-вельмі спрошчанай малюнку адсутнічаюць магістралі, кольцы, ip/mpls маршрутызацыя.
Яе сутнасць у тым, што трафік карыстальнікаў у канчатковым выніку прыходзіў у камутацыю ўзроўню ядра - адкуль ішоў у , адкуль, як правіла - назад у камутацыю ядра, і далей "на выхад" - праз адзін або некалькі border gateway's у інтэрнэт.
Падобная схема вельмі-вельмі лёгка рэзервуецца як на L3 (дынамічнай маршрутызацыяй), так і на L2 (MPLS).
Можна паставіць N+1 чаго заўгодна: сервераў доступу, камутатараў, бордэраў - і так ці інакш іх зарэзерваваць для аўтаматычнага фэйлавера.
Праз некалькі гадоў усім у Расіі стала зразумела, што так далей жыць нельга: неабходна тэрмінова абараніць дзяцей ад тлятворнага ўплыву сеткі.
Узнікла неабходнасць тэрмінова адшукваць спосабы фільтраваць карыстацкі трафік.
Тут ёсьць розныя падыходы.
У не вельмі добрым выпадку - нешта ставіцца «у разрэз»: паміж карыстацкім трафікам і інтэрнэтам. Трафік, які праходзіць праз гэтае «нешта», падвяргаецца аналізу і, напрыклад, у бок абанента адпраўляецца падроблены пакет з рэдырэктам.
У крыху лепшым выпадку - калі аб'ёмы трафіку дазваляюць - можна зрабіць невялікі фінт вушамі: адпраўляць на фільтрацыю толькі выходны ад карыстальнікаў трафік толькі на тыя адрасы, якія неабходна фільтраваць (для гэтага можна альбо браць з рэестра паказаныя там IP-адрасы, альбо дадаткова рэзалвіць наяўныя у рэестры дамены).
У свой час для гэтых мэт я напісаў просценькі — хаця нават язык не паварочваецца яго так называць. Ён вельмі просты і не вельмі прадукцыйны – аднак і нам, і дзясяткам (калі не сотням) іншых правайдэраў ён дазволіў не выкладваць адразу мільёны на прамысловыя DPI-сістэмы, а даў некалькі дадатковых гадоў часу.
Дарэчы, аб тагачасных і цяперашніх DPIДарэчы сказаць, многія, хто набыў наяўныя на той момант на рынку DPI-сістэмы – ужо іх выкінулі. Ну не заточаныя яны пад падобнае: сотні тысяч адрасоў, дзясяткі тысяч URL.
І ў той жа час пад гэты рынак вельмі моцна падняліся айчынныя вытворцы. Я не кажу пра апаратны складнік – тут усім усё зразумела, аднак софт – галоўнае, што ёсць у DPI – магчыма, на сёння калі не самы прасунуты ў свеце, то ўжо сапраўды а) развіваецца сямімільнымі крокамі, і б) па кошце скрынкавага – проста несупаставімы з замежнымі канкурэнтамі.
Хацелася б ганарыцца, але крыху сумна =)
Цяпер усё выглядала так:
Яшчэ праз пару гадоў ва ўсіх ужо стаялі рэвізоры; рэсурсаў у рэестры рабілася ўсё больш і больш. Для некаторага старога абсталявання (напрыклад, cisco 7600) станавілася проста непрыдатнай схема з "фільтраваннем узбоч": колькасць маршрутаў на 76 платформах абмежавана чымсьці каля дзевяціста тысяч, у той час, як колькасць толькі IPv4-маршрутаў сёння ўжо падбіраецца да 800 тысяч. А калі яшчэ і ipv6… А яшчэ і… колькі там? 900000 асобных адрасоў у лазні РКН? =)
Хтосьці пераходзіў на схему з люстраваннем усяго магістральнага трафіку на які фільтруе сервер, які павінен аналізаваць увесь струмень і пры знаходжанні чагосьці нядобрага слаць у абодва бакі (адпраўніку і атрымальніку) RST.
Аднак чым больш трафіку, тым менш дастасавальная падобная схема. Пры найменшай затрымцы ў апрацоўцы - люстраваны трафік проста неўзаметку праляціць унікуды, а правайдэру прыляціць пратакол аб штрафе.
Усё больш і больш правайдэраў змушана ставіць DPI-сістэмы рознай ступені надзейнасці ў разрэз магістраляў.
Год-два таму па чутках, практычна ва ўсіх ФСБ стала патрабаваць рэальную ўстаноўку абсталявання (раней большая частка правайдэраў абыходзілася ўзгадненнем з органамі плана САВМ - планам аператыўных мерапрыемстваў на выпадак неабходнасці нешта дзесьці знайсці)
Апроч грошай (не так, каб прама ўжо зусім зааблочных, але ўсё ж — мільёнаў), САВМ у шматлікіх запатрабаваў чарговых маніпуляцый з сеткай.
- СОРМу неабходна бачыць «шэрыя» адрасы карыстальнікаў, да nat-транслявання
- У СОРМа абмежаваны лік сеткавых інтэрфейсаў
Таму нам, у прыватнасці, прыйшлося выдатна перабудаваць кавалак ядра - проста для таго, каб сабраць дзесьці ў адным месцы трафік карыстальнікаў да сервераў доступу. Для таго, каб некалькімі лінкамі адлюстраваць яго ў САВМ.
Гэта значыць, вельмі спрошчана, было (злева) vs стала (справа):
Зараз у большасці правайдэраў патрабуюць укаранення таксама і САВМ-3 - які ўключае ў сябе, у тым ліку, і лагіраванне нат-трансляцый.
У гэтых мэтах у схему вышэй нам прыйшлося дадаць яшчэ і асобнае абсталяванне для NAT`а (як раз тое, пра якое ідзе гаворка ў першай частцы). Прычым дадаць у вызначаным парадку: паколькі САВМ павінен «бачыць» трафік да транслявання адрасоў - трафік павінен ісці строга наступным чынам: карыстачы -> камутацыя, ядро -> серверы доступу -> САВМ -> НАТ -> камутацыя, ядро -> інтэрнэт. Для гэтага нам прыйшлося, літаральна, "разгортваць" струмені трафіку ў іншы бок нажывую, што таксама было даволі няпроста.
Разам: за дзясятак гадоў схема ядра сярэдняга правайдэра ўскладнілася ў разы, а дадатковых кропак адмовы (як у выглядзе абсталявання, так і ў выглядзе адзіных камутацыйных ліній) - значна дадалося. Уласна, само па сабе патрабаванне "бачыць усё" мае на ўвазе звядзенне гэтага "усяго" ў адну кропку.
Думаецца мне, гэта цалкам празрыста можна экстрапаляваць на бягучыя ініцыятывы па суверэнізацыі рунэту, яго абароне, стабілізацыі і паляпшэнню 🙂
А наперадзе яшчэ Яравая.
Крыніца: habr.com