Развёрнутый ответ на комментарий, а также немного о жизни провайдеров в РФ

в 15:25, , рубрики: Законодательство в IT, интернет, Рунет Сегодня, Сетевые технологии, Суверенный интернет

Сподвиг меня на этот пост вот этот вот комментарий.

Привожу его здесь:

kaleman сегодня в 18:53

Меня сегодня порадовал провайдер. Вместе с обновление системы блокирования сайтов, у него под бан попал почтовик mail.ru С утра дергаю техподдержку, ничего сделать не могут. Провайдер маленький, и блокируют видимо вышестоящие провайдеры. Еще заметил замедление открытие всех сайтов, может какое-то кривое DLP навесили? Раньше никаких проблем с доступом не было. Уничтожение рунета идет прямо на моих глазах…

Дело в том, что, похоже, мы и есть тот самый провайдер :(

И действительно, kaleman почти угадал с причиной проблем с mail.ru (хотя мы долго отказывались верить в подобное).

Дальнейшее будет разделено на две части:

  1. причины наших сегодняшних проблем с mail.ru и увлекательный квест по их поиску
  2. существование ISP в сегодняшних реалиях, стабильность суверенного рунета.

Проблемы с доступностью mail.ru

Ох, это довольно долгая история.

Дело в том, что для реализации требований государства (подробнее во второй части) нами было приобретено, настроено, установлено некоторое оборудование — как для фильтрации запрещённых ресурсов, так и для осуществления NAT-трансляций абонентов.

Некоторое время назад мы наконец перестроили ядро сети таким образом, чтобы весь трафик абонентов проходил через это оборудование строго в нужном направлении.

Несколько дней назад включили на нём фильтрацию запрещёнки (одновременно оставив работать и старую систему) — с виду всё прошло хорошо.

Далее — постепенно стали включать для разных частей абонентов NAT на этом оборудовании. С виду — тоже всё, вроде бы, пошло неплохо.

Но сегодня, включив на оборудовании NAT для очередной части абонентов — с самого утра столкнулись с приличным количеством жалоб о недоступности или частичной доступности mail.ru и других ресурсов Mail Ru Group.

Стали проверять: что-то где-то иногда, изредка шлёт TCP RST в ответ на запросы исключительно к сетям mail.ru. Более того — шлёт неверно сгенерированный (без ACK), явно искусственный TCP RST. Примерно так это выглядело:

image

image

image

Естественно, первые мысли были о новом оборудовании: страшный DPI, доверия к нему никакого, мало ли что он может учудить — ведь TCP RST — это довольно распространённая штука среди средств блокировок.

Предположение kaleman о том, что фильтрует кто-то «вышестоящий», мы тоже выдвинули — но тут же отбросили.

Во-первых, у нас достаточно вменяемые аплинки, чтобы подобным не страдать :)

Во-вторых, мы подключены к нескольким IX в Москве, и трафик до mail.ru идёт именно через них — а уж у них нет ни обязанностей, ни какого-либо другого мотива фильтровать трафик.

Следующая половина дня была потрачена на то, что обычно называют шаманством — вместе с вендором оборудования, за что им спасибо, не бросили :)

  • полностью отключалась фильтрация
  • отключался NAT по новой схеме
  • тестовый ПК выносился в отдельный изолированный пул
  • менялась IP-адресация

Во второй половине дня была выделена виртуалка, выходящая в сеть по схеме обычного пользователя, и к ней и к оборудованию был дан доступ представителям вендора. Шаманство продолжалось :)

В конце концов представитель вендора уверенно заявил, что железка совершенно точно ни при чём: rst`ы приходят откуда-то выше.

Примечание

В этом месте кто-то может заявить: но ведь гораздо проще было снять дамп не с тестового ПК, а с магистрали выше DPI?

Нет, к сожалению, снять дамп (и даже просто отмиррорить) 40+gbps — совсем не тривиально.

После этого, уже вечером — не оставалось ничего другого, как вернуться к предположению о странной фильтрации где-то выше.

Я посмотрел, через какой IX сейчас ходит трафик до сетей МРГ и просто погасил к нему bgp-сессии. И — о чудо! — всё немедленно нормализовалось :(

С одной стороны — очень жаль, что на поиск проблемы был потрачен весь день, хотя решалась она за пять минут.

С другой стороны:

— на моей памяти это беспрецедентная штука. Как я уже писал выше — IX`ам действительно нет никакого смысла фильтровать транзитный трафик. У них его обычно сотни гигабит / терабиты в секунду. Я просто до последнего не мог всерьёз подобного предположить.

— невероятно удачное стечение обстоятельств: новое сложное железо, которому нет особого доверия и от которого непонятно, чего можно ждать — заточенное как раз под блокировку ресурсов, в том числе TCP RST`ами

В настоящий момент NOC этого internet exchange ищет проблему. По их утверждению (и я им верю) никакой специально развёрнутой системы фильтрации у них нет. Но, благодарение небу, дальнейший квест — уже не наша проблема :)

Это была небольшая попытка оправдаться, просим понять и простить :)

P.S.: я намеренно не называю ни производителя DPI/NAT, ни IX (у меня, собственно, даже нет к ним особых претензий, главное — понять, что это было)

Сегодняшняя (а также вчерашняя и позавчерашняя) реальность с точки зрения интернет-провайдера

Последние недели я провёл, значительно перестраивая ядро сети, производя кучу манипуляций «наживую», с риском значительно затронуть живой пользовательский трафик. Учитывая цели, результаты и последствия всего этого — морально всё это достаточно тяжело. Особенно — в очередной раз слушая прекраснодушные речи о защите стабильности рунета, суверенитете, и т.д. и т.п.

В этом разделе я попытаюсь рассказать «эволюцию» ядра сети типичного интернет-провайдера за последний десяток лет.

Десяток лет назад.

В те благословенные времена ядро провайдерской сети могло быть простым и надёжным, как пробка:

image

На этой очень-очень упрощённой картинке отсутствуют магистрали, кольца, ip/mpls маршрутизация.

Её суть в том, что трафик пользователи в конечном итоге приходил в коммутацию уровня ядра — откуда шёл в BNG, откуда, как правило — обратно в коммутацию ядра, и далее «на выход» — через один или несколько border gateway's в интернет.

Подобная схема очень-очень легко резервируется как на L3 (динамической маршрутизацией), так и на L2 (MPLS).

Можно поставить N+1 чего угодно: серверов доступа, коммутаторов, бордеров — и так или иначе их зарезервировать для автоматического фэйловера.

Через несколько лет всем в России стало понятно, что так дальше жить нельзя: необходимо срочно защитить детей от тлетворного влияния сети.

Возникла необходимость срочно изыскивать способы фильтровать пользовательский трафик.

Тут есть разные подходы.

В не очень хорошем случае — что-то ставится «в разрез»: между пользовательским трафиком и интернетом. Проходящий через это «что-то» трафик подвергается анализу и, например, в сторону абонента отправляется поддельный пакет с редиректом.

В немного лучшем случае — если обьёмы трафика позволяют — можно сделать небольшой финт ушами: отправлять на фильтрацию только исходящий от пользователей трафик только на те адреса, которые необходимо фильтровать (для этого можно либо брать из реестра указанные там IP-адреса, либо дополнительно резолвить имеющиеся в реестре домены).

В своё время для этих целей я написал простенький мини-dpi — хотя даже язык не поворачивается его так называть. Он очень простой и не очень производительный — однако и нам, и десяткам (если не сотням) других провайдеров он позволил не выкладывать сразу миллионы на промышленные DPI-системы, а дал несколько дополнительных лет времени.

К слову, о тогдашних и нынешних DPI

К слову сказать, многие, кто приобрёл имеющиеся на тот момент на рынке DPI-системы — уже их выкинули. Ну не заточены они под подобное: сотни тысяч адресов, десятки тысяч URL.

И в то же время под этот рынок очень сильно поднялись отечественные производители. Я не говорю про аппаратную составляющую — тут всем всё понятно, однако софт — главное, что есть в DPI — возможно, на сегодня если не самый продвинутый в мире, то уж точно а) развивается семимильными шагами, и б) по цене коробочного — просто несопоставим с зарубежными конкурентами.

Хотелось бы погордиться, но немного грустно =)

Теперь всё выглядело так:

image

Ещё через пару лет у всех уже стояли ревизоры; ресурсов в реестре становилось всё больше и больше. Для некоторого старого оборудования (например, cisco 7600) становилась просто неприменимой схема с «фильтрацией сбоку»: число маршрутов на 76 платформах ограничено чем-то около девятиста тысяч, в то время, как число только IPv4-маршрутов сегодня уже подбирается к 800 тысячам. А если ещё и ipv6… А ещё и… сколько там? 900000 отдельных адресов в бане ркн? =)

Кто-то переходил на схему с зеркалированием всего магистрального трафика на фильтрующий сервер, который должен анализировать весь поток и при нахождении чего-то нехорошего слать в обе стороны (отправителю и получателю) RST.

Однако чем больше трафика, тем менее применима подобная схема. При малейшей задержке в обработке — зеркалированный трафик просто незаметно пролетит вникуда, а провайдеру прилетит протокол о штрафе.

Всё больше и больше провайдеров вынуждено ставить DPI-системы разной степени надёжности в разрез магистралей.

Год-два назад по слухам, практически у всех ФСБ стало требовать реальную установку оборудования СОРМ (ранее большая часть провайдеров обходилась согласованием с органами плана СОРМ — планом оперативных мероприятий на случай необходимости что-то где-то найти)

Помимо денег (не так, чтобы прямо уж совсем заоблачных, но всё же — миллионов), СОРМ у многих потребовал очередных манипуляций с сетью.

  • СОРМу необходимо видеть «серые» адреса пользователей, до nat-транслирования
  • У СОРМа ограниченное число сетевых интерфейсов

Поэтому нам, в частности, пришлось здорово перестроить кусок ядра — просто для того, чтобы собрать где-то в одном месте трафик пользователей к серверам доступа. Для того, чтобы несколькими линками отзеркалировать его в СОРМ.

То есть, очень упрощённо, было (слева) vs стало (справа):

image

Сейчас у большинства провайдеров требуют внедрения также и СОРМ-3 — который включает в себя, в том числе, и логирование нат-трансляций.

В этих целях в схему выше нам пришлось добавить ещё и отдельное оборудование для NAT`а (как раз то, о котором идёт речь в первой части). Причём добавить в определённом порядке: поскольку СОРМ должен «видеть» трафик до транслирования адресов — трафик должен идти строго следующим образом: пользователи -> коммутация, ядро -> серверы доступа -> СОРМ -> НАТ -> коммутация, ядро -> интернет. Для этого нам пришлось, буквально, «разворачивать» потоки трафика в другую сторону наживую, что тоже было довольно непросто.

Итого: за десяток лет схема ядра среднего провайдера усложнилась в разы, а дополнительных точек отказа (как в виде оборудования, так и в виде единых коммутационных линий) — значительно прибавилось. Собственно, само по себе требование «видеть всё» подразумевает сведение этого «всего» в одну точку.

Думается мне, это вполне прозрачно можно экстраполировать на текущие инициативы по суверенизации рунета, его защите, стабилизации и улучшению :)

А впереди ещё Яровая.

Автор: Wingman

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js