Подтикна ме към този пост .
Цитирам го тук:
днес в 18:53ч
Днес бях доволен от доставчика. Заедно с актуализацията на системата за блокиране на сайта му беше забранен мейлърът mail.ru От сутринта звъня на техническа поддръжка, но те не могат да направят нищо. Доставчикът е малък и явно по-високопоставените го блокират. Забелязах и забавяне на отварянето на всички сайтове, може би са инсталирали някакъв крив DLP? Преди това нямаше проблеми с достъпа. Унищожаването на RuNet се случва точно пред очите ми...
Факт е, че изглежда сме същият доставчик :)
И наистина, Почти познах причината за проблемите с mail.ru (въпреки че дълго време отказвахме да повярваме в такова нещо).
Това, което следва, ще бъде разделено на две части:
- причините за настоящите ни проблеми с mail.ru и вълнуващото търсене да ги намерим
- съществуването на ISP в днешните реалности, стабилността на суверенния RuNet.
Проблеми с достъпността на mail.ru
О, това е доста дълга история.
Факт е, че за да изпълним изискванията на държавата (повече подробности във втората част), ние закупихме, конфигурирахме и инсталирахме оборудване - както за филтриране на забранени ресурси, така и за внедряване абонати.
Преди известно време най-накрая възстановихме ядрото на мрежата по такъв начин, че целият абонатен трафик преминаваше през това оборудване строго в правилната посока.
Преди няколко дни включихме забранено филтриране на него (докато оставихме старата система да работи) - всичко изглеждаше наред.
След това те постепенно започнаха да активират NAT на това оборудване за различни части от абонатите. От гледна точка всичко също изглеждаше добре.
Но днес, след като активирахме NAT на оборудването за следващата част от абонатите, от самата сутрин се сблъскахме с приличен брой оплаквания за недостъпност или частична наличност и други ресурси на Mail Ru Group.
Започнаха да проверяват: нещо някъде понякога, от време на време изпраща в отговор на заявки изключително към мрежите на mail.ru. Освен това той изпраща неправилно генериран (без ACK), очевидно изкуствен TCP RST. Ето как изглеждаше:
Естествено, първите мисли бяха за новото оборудване: ужасен DPI, никакво доверие в него, никога не знаеш какво може да направи - в крайна сметка TCP RST е доста често срещано нещо сред блокиращите инструменти.
предположение Изложихме и идеята, че някой „по-висш“ филтрира, но веднага я отхвърлихме.
Първо, имаме достатъчно здрави ъплинкове, за да не се налага да страдаме така :)
Второ, ние сме свързани с няколко в Москва и трафикът към mail.ru минава през тях - и те нямат нито отговорности, нито някакъв друг мотив да филтрират трафика.
Следващата половина от деня мина в това, което обикновено се нарича шаманство - заедно с продавача на оборудването, за което им благодарим, не се отказаха :)
- филтрирането беше напълно деактивирано
- NAT беше деактивиран с помощта на новата схема
- тестовият компютър беше поставен в отделен изолиран пул
- IP адресът е променен
Следобед беше разпределена виртуална машина, която се свърза към мрежата по схемата на обикновен потребител, а представители на доставчика получиха достъп до нея и оборудването. Шаманството продължи :)
В крайна сметка представителят на доставчика уверено заяви, че хардуерът няма абсолютно нищо общо с това: първите идват от някъде по-високо.
ВниманиеВ този момент някой може да каже: но беше много по-лесно да вземете дъмп не от тестовия компютър, а от магистралата над DPI?
Не, за съжаление вземането на дъмп (и дори само дублиране) 40+gbps не е никак тривиално.
След това, вечерта, не остана нищо друго освен да се върнем към предположението за странна филтрация някъде горе.
Погледнах през кой IX сега минава трафикът към MRG мрежите и просто анулирах bgp сесиите към него. И – ето! - всичко веднага се върна към нормалното 🙁
От една страна е жалко, че целият ден беше прекаран в търсене на проблема, въпреки че беше решен за пет минути.
От друга страна:
— според мен това е безпрецедентно нещо. Както вече писах по-горе - IX наистина няма смисъл от филтриране на транзитния трафик. Те обикновено имат стотици гигабита/терабита в секунда. Просто не можех сериозно да си представя нещо подобно доскоро.
— невероятно щастливо стечение на обстоятелствата: нов сложен хардуер, който не се ползва с особено доверие и от който не е ясно какво може да се очаква — пригоден специално за блокиране на ресурси, включително TCP RST
NOC на този интернет обмен в момента търси проблем. Според тях (и аз им вярвам), те нямат никаква специално внедрена система за филтриране. Но, слава Богу, по-нататъшното търсене вече не е наш проблем :)
Това беше малък опит да се оправдая, моля за разбиране и извинение :)
PS: Съзнателно не посочвам производителя на DPI/NAT или IX (всъщност дори нямам специални оплаквания за тях, основното е да разбера какво е)
Днешната (както и вчерашната и завчерашната) реалност от гледна точка на интернет доставчик
Прекарах последните седмици в значително възстановяване на ядрото на мрежата, извършвайки куп манипулации „с цел печалба“, с риск да засегна значително потребителския трафик на живо. Имайки предвид целите, резултатите и последствията от всичко това, морално всичко е доста трудно. Особено - отново слушайки красиви речи за защита на стабилността на Runet, суверенитета и т.н. и така нататък.
В този раздел ще се опитам да опиша „еволюцията“ на мрежовото ядро на типичен интернет доставчик през последните десет години.
Преди десет години.
В онези благословени времена ядрото на мрежата на доставчик може да бъде толкова просто и надеждно, колкото задръстване:
В тази много, много опростена картина няма стволове, пръстени, ip/mpls маршрутизиране.
Същността му е, че потребителският трафик в крайна сметка е стигнал до превключването на ниво ядро - откъдето е отишъл , откъдето, като правило, обратно към основното превключване и след това „навън“ - през един или повече гранични шлюза към Интернет.
Такава схема е много, много лесна за резервиране както на L3 (динамично маршрутизиране), така и на L2 (MPLS).
Можете да инсталирате N+1 от всичко: сървъри за достъп, превключватели, граници - и по един или друг начин да ги запазите за автоматичен отказ.
След няколко години На всички в Русия стана ясно, че вече не е възможно да се живее така: трябва спешно да се защитят децата от пагубното влияние на интернет.
Имаше спешна нужда да се намерят начини за филтриране на потребителския трафик.
Тук има различни подходи.
В не много добър случай нещо се поставя „в празнината“: между потребителския трафик и интернет. Трафикът, преминаващ през това „нещо“, се анализира и например към абоната се изпраща фалшив пакет с пренасочване.
В малко по-добър случай - ако обемът на трафика позволява - можете да направите малък трик с ушите си: изпращайте за филтриране само трафик, произхождащ от потребители, само до онези адреси, които трябва да бъдат филтрирани (за да направите това, можете или да вземете IP адресите посочени там от регистъра или допълнително разрешаване на съществуващи домейни в регистъра).
По едно време за тези цели написах прост - въпреки че дори не смея да го нарека така. Това е много просто и не много продуктивно - въпреки това позволи на нас и десетки (ако не и стотици) други доставчици да не отделим веднага милиони за индустриални DPI системи, но даде няколко допълнителни години време.
Между другото, за тогавашния и сегашния DPIМежду другото, мнозина, които са закупили DPI системите, налични на пазара по това време, вече са ги изхвърлили. Е, те не са предназначени за това: стотици хиляди адреси, десетки хиляди URL адреси.
И в същото време местните производители се издигнаха много силно на този пазар. Не говоря за хардуерния компонент - всичко е ясно за всички тук, но софтуерът - основното нещо, което DPI има - е може би днес, ако не и най-напредналият в света, то със сигурност а) развива се скокообразно, и б) на цената на опакован продукт - просто несравнима с чуждестранните конкуренти.
Бих искал да съм горд, но малко тъжен =)
Сега всичко изглеждаше така:
След още няколко години всички вече имаха одитори; Имаше все повече и повече ресурси в регистъра. За някои по-стари устройства (например Cisco 7600) схемата за „странично филтриране“ просто стана неприложима: броят на маршрутите на 76 платформи е ограничен до около деветстотин хиляди, докато броят на IPv4 маршрутите днес наближава 800 хиляди. И ако е и ipv6... И също така... колко е там? 900000 XNUMX индивидуални адреса в забраната на RKN? =)
Някой е преминал към схема с отразяване на целия опорен трафик към филтриращ сървър, който трябва да анализира целия поток и ако се открие нещо лошо, да изпрати RST в двете посоки (подател и получател).
Въпреки това, колкото повече трафик, толкова по-малко приложима е тази схема. Ако има и най-малкото забавяне в обработката, огледалният трафик просто ще прелети незабелязано и доставчикът ще получи фин отчет.
Все повече и повече доставчици са принудени да инсталират DPI системи с различна степен на надеждност по магистралите.
Преди година-две според слуховете, почти всички ФСБ започнаха да изискват действително инсталиране на оборудване (преди повечето доставчици управляваха с одобрение от властите План SORM - план за оперативни мерки в случай на нужда да се намери нещо някъде)
Освен пари (не точно прекомерни, но все пак милиони), SORM изискваше много повече манипулации с мрежата.
- SORM трябва да види „сивите“ потребителски адреси преди nat превод
- SORM има ограничен брой мрежови интерфейси
Ето защо, по-специално, трябваше значително да преустроим част от ядрото - просто за да съберем потребителския трафик към сървърите за достъп някъде на едно място. За да го огледате в SORM с няколко връзки.
Тоест, много опростено, беше (вляво) срещу стана (вдясно):
Сега Повечето доставчици също изискват прилагането на SORM-3 - което включва, наред с други неща, регистриране на nat излъчвания.
За тези цели също трябваше да добавим отделно оборудване за NAT към диаграмата по-горе (точно това, което се обсъжда в първата част). Освен това добавете в определен ред: тъй като SORM трябва да „види“ трафика преди превод на адреси, трафикът трябва да върви стриктно както следва: потребители -> превключване, ядро -> сървъри за достъп -> SORM -> NAT -> превключване, ядро - > Интернет. За да направим това, трябваше буквално да „обърнем“ трафик потоците в другата посока за печалба, което също беше доста трудно.
В обобщение: през последните десет години основният дизайн на средностатистическия доставчик стана многократно по-сложен и допълнителните точки на повреда (както под формата на оборудване, така и под формата на единични превключващи линии) се увеличиха значително. Всъщност самото изискване „да се види всичко“ предполага свеждането на това „всичко“ до една точка.
Мисля, че това може да бъде доста прозрачно екстраполирано към настоящите инициативи за суверенизиране на Runet, защитата му, стабилизирането му и подобряването му :)
И Яровая все още е напред.
Източник: www.habr.com