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

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

Привожу его здесь:
kaleman сегодня в 18:53

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

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

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

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

  • Проблемы с доступностью mail.ru
    Ох, это довольно долгая история.

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

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

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

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

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

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

    Естественно, первые мысли были о новом оборудовании: страшный 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 (у меня, собственно, даже нет к ним особых претензий, главное — понять, что это было)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Оставить комментарий