Подтикна ме да напиша този пост .
Давам го тук:
днес в 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 е доста разпространен феномен сред средствата за блокиране.
Предположение относно това, че някой „по-горен“ филтрира, също беше изказано от нас — но веднага го отхвърлихме.
Първо, имаме достатъчно адекватни uplinks, за да не страдаме от подобни неща 🙂
На второ място, сме свързани с няколко в Москва, и трафикът до mail.ru минава именно през тях — а те нямат нито задължения, нито какъвто и да е друг мотив да филтрират трафика.
Следващата половина от деня беше прекарана в това, което обикновено се нарича шаманство — за което благодаря на доставчика на оборудването, не ни оставиха 🙂
- филтрацията беше напълно деактивирана
- NAT беше изключен по нова схема
- тестовият компютър беше поставен в отделен изолиран пул
- IP адресацията беше променена
През втората половина на деня беше отделена виртуалка, която излизаше в мрежата по схемата на обикновения потребител, и на нея и на оборудването беше предоставен достъп на представителите на доставчика. Шаманството продължи 🙂
Накрая представителят на доставчика уверено заяви, че устройството абсолютно не е във виновник: rst'ите идват отгоре.
ЗабележкаВ този момент някой може да заяви: но нали беше много по-лесно да се вземе дъмп не от тестовия компютър, а от магистрала над DPI?
Не, за съжаление, вземането на дъмп (и дори просто мироренето) на 40+gbps е съвсем не тривиално.
След това, вече вечерта — нямаше нищо друго, освен да се върна към предположението за странно филтриране някъде по-горе.
Погледнах през кой IX в момента минава трафикът до мрежите на МРГ и просто изключих bgp-сесиите с него. И — о, чудо! — всичко веднага се нормализира 🙁
От една страна — много съжалявам, че целият ден беше похарчен за търсене на проблема, въпреки че решението му отне пет минути.
От друга страна:
— на паметта ми, това е безпрецедентен случай. Както вече писах по-горе — IX'ите наистина нямат никакъв смисъл да филтрират транзитния трафик. Обикновено имат стотици гигабита / терабита в секунда. Просто до последно не можех да повярвам, че е възможно.
— невероятно късметлийска случайност: ново сложно оборудване, на което няма особено доверие и от което не е ясно какво да се очаква — предназначено точно за блокиране на ресурси, включително TCP RST'и
В момента NOC на този интернет обмен търси проблема. Според тях (и им вярвам) нямат специално развърната система за филтрация. Но, благодаря на небето, следващата квест — вече не е наш проблем 🙂
Това беше малко опит за оправдание, молим ви да разберете и простите 🙂
P.S.: Умишлено не споменавам нито производителя на DPI/NAT, нито IX (всъщност нямам особени претенции към тях, важното е да се разбере какво се случи)
Днешната (както и вчерашната и завчерашната) реалност от гледната точка на интернет доставчика
Последните седмици прекарах, значително преструктурирайки ядрото на мрежата, извършвайки куп манипулации 'на живо', с риск значително да засегна активния потребителски трафик. Като се вземат предвид целите, резултатите и последствията от всичко това — морално всичко това е доста трудно. Особено — отново слушайки прекраснодушни речи за защита на стабилността на рунета, суверенитета и т.н.
В този раздел ще се опитам да разкажа 'еволюцията' на ядрото на мрежата на типичен интернет доставчик през последното десетилетие.
Десет години назад.
В онези благословени времена ядрото на доставчикската мрежа можеше да бъде простичко и надеждно като тапа:
На тази много-очевидно опростена картинка липсват магистрали, пръстени, ip/mpls маршрутизиране.
Същността му е, че трафикът на потребителите в крайна сметка достига до комутацията на ядрото — откъдето се отправя към , откъдето, като правило — обратно в ядрото на свързването, и по-нататък «на изход» — през един или повече border gateway в интернет.
Подобна схема много-очевидно лесно се резервира както на L3 (динамично маршрутизиране), така и на L2 (MPLS).
Може да се постави N+1 от каквото и да било: достъпни сървъри, комутатори, бордери — и така или иначе да се резервират за автоматично фейловер.
След няколко години на всички в Русия стана ясно, че така повече не може да се живее: необходимо е спешно да се защитят децата от пагубното влияние на мрежата.
Възникна необходимост спешно да се намерят начини за филтриране на потребителския трафик.
Тук има различни подходи.
В не много добрия случай — нещо се поставя 'в разрез': между потребителския трафик и интернет. Преминаващият през това 'нещо' трафик подлежи на анализ и, например, в посока към абоната се изпраща фалшив пакет с редирект.
В малко по-добър случай – ако обемите на трафика позволяват – може да се направи малък трик: да се изпраща за филтриране само изходящият трафик от потребителите към адресите, които трябва да се филтрират (за това може или да се вземат IP адресите, посочени в регистъра, или да се извърши допълнително резолвиране на наличните в регистъра домейни).
В свое време за тези цели написах простичък – въпреки че дори езикът не ми позволява да го нарека така. Той е много прост и не особено ефективен – обаче и на нас, и на десетки (ако не и стотици) други доставчици той ни позволи да не инвестираме веднага милиони в промишлени DPI системи, а ни даде няколко допълнителни години.
Струва ми се, че по въпроса за тогавашните и настоящите DPIСтрува ми се, че много от тези, които закупиха наличните на пазара по онова време DPI системи – вече ги изхвърлиха. Не са пригодени за подобно: стотици хиляди адреси, десетки хиляди URL.
И в същото време в този сектор местните производители много активно се развиха. Не говоря за хардуерната част – тук всичко е ясно, но софтуерът – основното, което има в DPI – е вероятно днес, ако не най-напредналият в света, то определено а) напредва с гигантски крачки и б) на цената на кутията – просто несравним с чуждестранните конкуренти.
Иска ми се да се гордея, но е малко тъжно =)
Сега всичко изглеждаше така:
Още след няколко години всички вече имаха ревизори; ресурсите в регистъра ставаха все повече и повече. За известно старо оборудване (например, cisco 7600) схемата с „филтриране отстрани“ просто стана неприлагана: числото на маршрутите на 76 платформите е ограничено до около деветстотин хиляди, докато броят само на IPv4 маршрутите днес вече наближава 800 хиляди. А ако добавим и ipv6... А и... колко там? 900000 отделни адреса в забраната на ркн? =)
Някой премина към схема с огледално копиране на целия магистралния трафик на филтриращ сървър, който трябва да анализира целия поток и при откритие на нещо нередно да изпраща в двете посоки (изпращача и получателя) RST.
Обаче колкото повече трафик, толкова по-малко приложима е подобна схема. При най-малко забавяне в обработката – огледалният трафик просто незабелязано ще премине никъде, а на доставчика ще бъде наложен протокол за глоба.
Все повече и повече доставчици са принудени да инсталират системи за DPI с различна степен на надеждност в магистралите.
Година-две назад по слухове, почти всички от ФСБ започнаха да изискват реално поставяне на оборудване (по-рано повечето доставчици успяваха да се справят със съгласуване с органите план за СОРМ — план за оперативни мероприятия в случай на необходимост да се намери нещо дори и на случаен принцип)
Освен парите (не точно небесни, но все пак — милиони), СОРМ от много изисква нови манипулации в мрежата.
- СОРМ трябва да вижда „сива“ адреса на потребителите, преди NAT транслацията
- СОРМ има ограничен брой мрежови интерфейси.
Затова, включително, ни се наложи да преработим част от ядрата — просто, за да съберем трафика на потребителите към сървърите за достъп на едно място. За да можем да го отразим в СОРМ с няколко линка.
Тоест, много опростено, беше (вляво) срещу това, което стана (вдясно):
Сега при повечето доставчици изискват също внедряването на СОРМ-3 — който включва и логиране на NAT транслации.
За тези цели в схемата по-горе ни се наложи да добавим и специално оборудване за NAT (точно това, за което се говори в първата част). Освен това, трябваше да добавим в определен ред: тъй като СОРМ трябва да „вижда“ трафика преди адресите да бъдат транслирани — трафикът трябва да следва стриктно следния маршрут: потребители -> комутация, ядро -> сървъри за достъп -> СОРМ -> NAT -> комутация, ядро -> интернет. За това, буквално, трябваше да „разделим“ потоките трафик на друга посока в реално време, което също беше доста сложно.
Следователно: през последното десетилетие схемата на ядрото на средния доставчик се усложни значително, а допълнителните точки на отказ (както под формата на оборудване, така и под формата на единични комутационни линии) значително нарастват. Всъщност, само по себе си искането „да се види всичко“ предполага свеждане на това „всичко“ до една точка.
Мисля, че това може да се екстраполират веднага в текущите инициативи за суверенитет на рунета, защитата му, стабилизацията и подобрението 🙂
А напред е още Яровая.
Източник: habr.com
