Главная » Хабрахабр » Технические аспекты блокировки интернета в России. Проблемы и перспективы

Технические аспекты блокировки интернета в России. Проблемы и перспективы

Начнем сразу с дисклеймера: ниже принципиально не будет политических вопросов. Административные и юридические вопросы тоже будем обходить настолько, насколько сможем, чтобы полностью не вырывать техническую часть из остальных плоскостей.

А раз так, нужно разбираться, как это устроено технически, что может и не может провайдер. Блокировки интернета в России уже есть — это данность, с которой мы живем и должны жить дальше. В итоге сейчас больше него о блокировках в России знает только Роскомнадзор, но это не точно. Филипп Кулин (schors) давно начал собирать информацию по этому поводу, участвовал в нормативной работе, ходил на разные совещания. Под катом краткая сводка актуального состояния дел.

О спикере: Филипп Кулин (schors) генеральный директор ООО «Дремучий лес» — небольшого российского хостера, занимающегося в основном shared-хостингом.

Сплошной клубок проблем

Казалось бы, есть блокировки и есть. Не нравятся они нам, но, может быть, ничего плохого в них нет?

На самом деле, блокировки — это сплошной клубок проблем.

Сопутствующий ущерб — самая большая проблема блокировок. Самый яркий пример, иллюстрирующий это, произошел в апреле 2018 года, когда были заблокированы большие блоки IP-адресов облачных сервисов, соответственно, многие сервисы не работали и понесли большой ущерб.

Год назад этот рассказ был бы абсолютно другим, а два года назад он, скорее всего, противоречил бы сегодняшнему. Волатильность нормативов и практик, которые все время изменяются. Сегодня это так, через месяц — немножко не так, а через полгода вообще не так. Через год снова все будет по-другому. За этим надо следить, но и успевать работать тоже надо.

Если какой-то ресурс попал в блокировку именно по реестру — это самый простой случай. Блокировки трудно диагностировать. Яркий пример — в октябре у Яндекса падал DNS часов на пять, за это время многие успели решить, что это блокировка Роскомнадзора. В случаях, которые мы рассмотрим дальше, отличить реальную блокировку от технических проблем достаточно сложно. Определить точно, действительно, трудно, а ситуации такие уже бывали, поэтому люди сразу думают о блокировке.

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

Очень хороший пример непредсказуемости рисков — это случай Битрикс24. Рассчитать риски совершенно невозможно, потому что, может быть, отвалится какой-то виджет на сайте, про который вы уже и забыли, а может и весь бизнес попасть под удар. В этом же месяце в сеть утек документ, который правда возможно был фейковый, в котором были прописаны большие подсети Amazon. В марте они очень быстро перенесли свои сервисы в Amazon. Тем не менее Битрикс24 как-то на него отреагировали и избежали проблем в апреле, когда сервисы Amazon действительно были заблокированы.

Такие документы не будут по счастливой случайности утекать вам в руки. Уверяю, большинству из вас так не повезет! Когда ваш бизнес закончится, вы узнаете об этом постфактум.

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

Можно с иронией рассуждать над, например, Дэвидом Хомаком и блокировкой Лурка. Все это приводит к некой безысходности. Клиент указал IP-адреса моих серверов у домена, которым я не управлял — я сижу, а телефон просто не умолкает. Но совсем другое дело, когда это происходит с вами, как один раз произошло со мной. И никто не может мне в этом помочь. Клиенты говорят, что они уходят, требуют вернуть деньги, а я сделать ничего не могу! Это реально ощущение полной безысходности.

Группы риска

Блокировки касаются:

  • Владельцев сайтов и сервисов, которых, в том числе, могут заблокировать по ошибке. Или могут признать какую-то информацию запрещенной.
  • Пользователей сервисов блокировки тоже касаются. То, что ваш сайт заблокировали, касается в первую очередь вас. Но ведь есть люди, которые этим сайтом или сервисом пользовались.
  • Хостеров и провайдеров, которые находятся между двумя огнями. Потому что от них требуется и работающие сервисы, и выполнение требований надзорного органа, который грозит штрафами. Напомню, что штрафы от 50 до 100 тысяч рублей за протокол. Таких протоколов, например, за месяц может быть много и суммы получаются очень существенные.

Принцип работы блокировок

Сначала кратко обсудим, как происходит блокировка, чтобы понимать полную картину.

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

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

Инструменты фильтрации

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

Либо можно использовать:

  • специальные комплексные коммерческие решения;
  • свободно распространяемые решения с открытым исходным кодом (на данный момент такой проект один);
  • свой «колхоз».

Там нет никакого рокетсайнс, и основные проблемы совсем не в том, чтобы написать программу.

Есть следующие варианты реализации.

Например, у вас есть небольшой канал в 100 Гбит, вы поставили фильтр в разрыв.

То есть фильтр пытается ответить быстрее нормального ответа, соответственно, если фильтр начал тормозить, — штрафы (напомню, 50-100 тысяч рублей).
Некоторые зеркалируют трафик, но с зеркалированием трафика проблема в том, что работает это как бы на опережение.

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

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

Плюс у крупных провайдеров, например, в МТС, есть специальные службы безопасности, которые специально ищут блоки IP c риском, которые тоже попадают в фильтрацию. Выборочная маршрутизация может дополняться тем, что наборы IP-адресов для фильтрации агрегируются в большую сторону. То есть блокируется не просто несколько адресов, а вся сразу сеть /24 попадает на фильтр.

Это популярный метод, которым пользуется, например, Дом.ru. Также выборочную маршрутизацию можно комбинировать с фильтрацией DNS-запросов.

Разберем поэтапно проблемы, которые все это приносит.

Принятие решения о блокировке

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

Хостер или владелец сайта не может контролировать, какие запросы к нему ведутся, никакой открытой информации нет. Из-за этого происходят всякие плохие вещи. С блокировками такого нет — вы рассчитываете только на то, что уведомление до вас дойдет, и вы его вовремя успеете прочитать. Например, у Google есть база сайтов с вирусами, где вы можете себя зарегистрировать как автономную систему, как-то подтвердить, что вы автономная система, и действительно самому смотреть, какие сайты по мнению Google в вашей автономной системе распространяют «зловреды».

Когда вам приходит уведомление, а вы говорите, что у вас нет такой информации и просите разъяснений, то можете получить ответ и через несколько недель. Сроки взаимодействия с Роскомнадзором не соблюдаются, и в целом немного странные, несмотря на то что есть нормативы — за сутки отправить уведомление, за сутки ответить, за сутки принять решение. Такие ситуации у меня были, но мало кто подает в суд — я вообще не знаю таких случаев. А, может, вас заблокируют, а потом ответят, что информация у вас таки есть.

В большинстве случаев Роскомнадзор нормально описывает, что имеет в виду. Опять же, если пришло уведомление, вы не всегда можете понять, о чем оно. Я даже не знал, что клиенту написать — протоколы и тексты решения Роскомнадзор выдает только по суду, хотя у них есть такие документы. Но даже в нашей практике микро-хостера было три случая, когда по описанию было непонятно, о какой информации речь.

Время применения «выгрузки»

Итак, решение приняли, провайдер скачал «выгрузку» и дальше должен с ней что-то сделать. Есть два варианта, насколько быстро: сутки или незамедлительно.

У многих это сделано, как ночные обновления коммутатора. Важно, что сутки отведены и на блокировку ресурса, и на разблокировку, если вдруг принято решение о разблокировке. А бизнес не ждет, появляются потери. Из моего опыта: не вовремя принял уведомление, ресурс заблокировали, вопрос решили, но сутки ждешь, пока разблокируют.

Но устная договоренность сегодня есть, а завтра ее нет. Но сейчас в нормативах очень часто звучит слово «незамедлительно», по устной договорённости это час. В основном формулировка «незамедлительно» сейчас касается прокурорских решений по экстремизму.

Там список записей в XML одного из четырех типов по видам блокировки и реквизиты решения: Чтобы понимать, как все фильтруется, надо знать, что находится внутри «выгрузки».

  1. URL(s) + домен + IP-адрес(а);
  2. Домен + IP-адрес(а);
  3. Домен с маской (*.example.com) + IP-адрес(а);
  4. IP-адрес(а) — понятно, есть адрес, и его полностью блокируем.

Чтобы было понятно, о каких цифрах идет речь, ниже статистика на 22 января 2019.

Это HTTP и HTTPS протоколы. Важно: всего 139 тысяч записей, а самый популярный тип блокировки — это блокировка «по домену».

Токсичность «выгрузки»

Перед тем, как блокировать ресурс, провайдер должен разобрать «выгрузку». С этим тоже есть проблемы. Я специально обратил внимание, что «выгрузка» — это не реестр, а некий технический документ, который провайдеру выдается для того, чтобы он на его основе принимал решения. Но несмотря на это, провайдеру приходится проводить очень большую обработку «выгрузки».

Если взять какой-то URL, это не значит, что не будет блокировки по домену, который содержится в этом URL. Например, в «выгрузке» есть избыточность, записи перекрывают друг друга. Таких сейчас не так много, правда, — чуть более трех тысяч.

Это вообще ужас, потому что надо понимать, как проходит проверка. В «выгрузке» содержатся URL с фрагментами (#) и сессиями.

Бывают пробелы, но их быстро убирают, а к обратным слешам почему-то особенная «любовь». Провайдер должен приводить «выгрузку» в нормальный вид, потому что в ней встречаются неправильные URL и домены. В основном сейчас встречаются только обратные слеши. Поэтому всегда должен быть мониторинг, всегда надо что-то делать. Ну ладно, с обратными слешами вопрос решили, а если появится какой-нибудь плюсик?

Что делает провайдер? Еще раз обращаю внимание, что проблема провайдера — это наша проблема. Мотивация в 100 тысяч рублей — это хорошая мотивация сделать так, чтобы вообще при любой проблеме, даже при любом намеке на проблему, рубить сразу, а потом разбираться.

Актуальность в «выгрузке» тех IP-адресов, которые не «блокировка по IP-адресам», а всех остальных (блокировки по домену, по URL, по маске) выглядит примерно так.

Буквально чуть больше половины актуально, а остальные полный фарш.

Проверка блокировок

Начну с конца.

Вся история реализации блокировок в России это история проверок этих блокировок.

Я не знаю, как заграницей, у нас это абсолютно точно именно история проверок. Все блокировки делаются не так, как написано, как их делать, а так, как проверят, потому что никому не нравится платить штрафы, особенно 100 тысяч.

Я микро-хостер и то умудрялся попадать на блокировку у меня таких ресурсов. До реестра запрещенных сайтов существовал список экстремистских материалов Минюста (он и сейчас существует, просто сейчас он в реестре, а тогда был отдельным) и прокурорские проверки блокировок по этому списку.

Существующие виды проверок:

  • Выездные проверки (в основном МВД, ФСБ и прокуратура) — они редкие, но есть.
  • АС «Ревизор» — любимая автоматизированная система, которая проверяет всех провайдеров.

Но сам прибор ничего не делает, он получает задачи и отдает ответы в некий центр управления, т.е. «Ревизор» стоит за фильтром и полностью прикидывается абонентом. Действует он очень похоже действует на RIPE Atlas. это такой удаленный shell внутрь сети провайдера.

То есть не у каждого провайдера, а в каждой сети каждого провайдера. Центр управления автоматизированной системы — это настоящий highload-сервис, потому что у нас 4 тысячи операторов связи, у них не по одной сети, а коробочка должна стоять в каждой сети. Соответственно, у центра управления есть определенные проблемы.

Конечно, есть. Вопрос: есть ли проблемы у самой проверки?

Проблемы проверки

На СПЕКТР-2017 (форум под эгидой самого Роскомнадзора) один из начальников ФГУП главного радиочастотного центра (ГРЧЦ) Вэклич А.А. сделал целый доклад о том, какие есть именно технические проблемы с проверкой «Ревизором» провайдеров.

Проблемы проверки:

  • Видит ли «Ревизор», это фильтр провайдера или ресурса? Может быть, это кто-то из вас нашел базу данных «Ревизора» и все сайты просто отдают заглушку, похожую на заглушку провайдера.
  • Показатель блокировки — для всех типов блокировки (для HTTPS, домена, IP-адреса) что является показателем того, что ресурс заблокирован? Например, по IP-адресу надо сканировать порты, это целая проблема.
  • Показатель блокировки для других протоколов.
  • Как проверить домен по маске? Под звездочкой могут быть разные IP-адреса, разные домены. Можно ставить фильтр на всю полосу? А проверять что — выборочно или какой-то хэш генерировать? Сразу скажу, нормативно такая блокировка есть, но ее никто не проверяет.

Методика работы АС «Ревизор»

В соответствии с этими проблемами создана методика работы «Ревизора».

Я не очень понимаю, как чисто логически с этим можно жить. И да, слайд ваше исчерпывающе иллюстрирует данную методику. Для нас это все выливается в то, что провайдеры пытаются как-то эту проблему решить, и делают это удобным для себя способом, и не всегда удобным для нас.

Вообще вся методика блокировки — это эмпирический путь, который стоит денег, нервов, падений, даже сейчас, когда какая-то методика уже немного устоялась. Работая без методики, многие провайдеры получили экзистенциальный опыт.

Самое интересное, что там можно получить реальную помощь, сотрудники ГРЧЦ помогают провайдерам решать их проблемы, и рассказывают, как работает «Ревизор». Есть неофициальный чатик (что примечательно — в Telegram, где же еще), где провайдеры общаются с сотрудниками Радиочастотного Центра. Но это все неофициально, нет никаких документов.

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

Методика работы с «выгрузкой»

По нормативу и по накопленному опыту, расскажу, как работают с «выгрузкой», то есть как наши ресурсы блокируются.

По URL:

  • Если это обычный протокол HTTP — фильтр по заголовкам.
  • Если шифрованный протокол HTTPS — фильтр как «домен»

Зачем там вообще URL с шифрованным протоколом неясно, это же избыточность.

По домену:

  • Обычный протокол HTTP — фильтр по заголовку Host.
  • Шифрованный протокол HTTPS — или фильтр DNS; или фильтр по заголовку SNI (при установлении шифрованного соединения передается нешифрованный заголовок с доменным именем внутри); или фильтр по IP-адресу.
  • Остальные протоколы рекомендуется блокировать как по IP-адресу, но поскольку «Ревизор» этого не проверяет, то кто-то делает, кто-то нет.

Норматив действительно говорит, что во втором случае блокировки «по домену» нельзя блокировать по IP-адресу. Но провайдер, когда у него начинает барахлить фильтр, включает сразу еще один уровень, чтобы не получить штраф. Такая история не редкость и естественно ведет к дополнительному ущербу для бизнеса.

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

По IP-адресу и блоку IP-адресов фильтруют, как умеют, — прямо на пограничном маршрутизаторе иногда.

Добросовестные участники

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

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

Проблемы фильтрации

Давайте разберем проблемы, поговорим о фильтрации DNS, которая рекомендуется нормативом.

Действительно, может быть размещена запрещенная информация, но DNS представляет нужный людям сервис, именно как DNS, например, IP-адреса. Первый вопрос: а причем тут DNS? При подделке DNS получается все не очень хорошо, и не понятно, почему так.

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

Тогда провайдер должен разработать систему и поддерживать ее. Все это можно ускорить, создав свою систему подмены ответов. Так тоже делают, но это редкость.

При распространении технологии шифрования запросов DNS (DNSCrypt, DoT, DoH) неизвестно останется ли тип блокировки по DNS.

Но что делать с остальными протоколами? С фильтрацией доменов по маске проблема в том, что домены могут быть на разных IP, то есть вам придется сканировать всю полосу HTTP/HTTPS. А проверки всё равно нет! Вы сканируете всю полосу, а, например, запретили только Telegram по маске (по домену) — что с этим делать?

Следующий очень важный момент — кстати, это наше будущее — что делать, если на порту 443: нет SNI, SNI шифрованный (ESNI) или вообще другие протоколы, например, QUIC, DNSCrypt, VPN, MTProto-proxy?

Сейчас этот вопрос каждый решает по-своему. Крупные компании, например, Google, уже поддерживают шифрованный SNI, а у Яндекса DNSCrypt на 443 порту. Точно статистики на эту тему я привести не могу, но сам подход не внушает оптимизма. Некоторые провайдеры, особенно мобильные, если не могут опознать трафик как HTTPS, просто его вырубают.

Резолвинг домена

Ставить фильтр на всю полосу, например, в 100 Гбит малореально. Вместо этого провайдеры берут домены, их IP-адреса, и уже этот трафик сканируют. Это делают и крупные, и мелкие провайдеры, в основном крупные, кстати говоря.

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

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

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

С резолвингом есть еще проблемы:

  • балансинг;
  • геотаргетинг;
  • миграция сервисов, в том числе и умышленная.

Примерно полгода назад от блокировок убегало около тысячи доменов. Причем неизвестно, специально они это делали или нет. Например, LiveJournal все заблокированные журналы почему-то откидывает на какой-то CDN, который по /23 раз в минуту меняет IP. Зачем так делают, не очень понятно, но такой факт есть.

«Протухшие» домены

Домен «протухает», когда у него закончился срок регистрации, но он остаётся в «выгрузке», потому что, естественно, никто за этим не следит. Новый владелец домена получает контроль над тем типом блокировки, которая в «выгрузке». В «выгрузке» могут быть и поддомены, а когда вы купили домен, вы получаете контроль над всеми поддоменами.

Мы не знаем, сколько доменов уже куплено людьми, которые решили пошутить. Я нашел в «выгрузке» около 200 «протухших» доменов, но на самом деле их там больше. Может, их нет, может есть.

К чему это приводит?

Справа график MSK-IX, который сам MSK-IX отрицает и говорит, что это был внутренний сбой. На картинке сбои сайтов Яндекса, ВКонтакте, Википедии. Но внутренний сбой почему-то по времени точно совпадал с DNS-атакой.

Кто-то поигрался, и так до сих пор и неизвестно, кто. DNS-атака заключалась в том, что кто-то купил «протухший» домен, кинул туда тысячи IP-адресов и начал поливать все, что хочет, то есть на эти IP-адреса кидать Яндекс, ВКонтакте и т.д.

Но несмотря на это, на графике справа внизу, который показывает количество доменов в «выгрузке», видно, что 5 июня 2017 года Роскомнадзор провел основательную чистку. Все, конечно, надували щеки и говорили, что такого быть не может.

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

Вы думаете, что кто-нибудь что-нибудь сделал?

Кто-то купил 4 домена, получил контроль над 400 поддоменов, и залил туда 4 000 IP-адресов. 14 марта 2018 год: другой вектор атаки, но тоже с «протухших» доменов. У ТрансТелеКома, у которого по заверениям Роскомнадзора все в порядке, где-то на 600 тысячах переполнилась таблица на маршрутизаторах, и 20% сетей ТTK по всей стране прилегло.

Не прошло и года:

5 мая я говорю Леониду Евдокимову: «А не пошутить ли нам — не написать ли на графике что-нибудь морзянкой?» Через час он это сделал. Это график резолвинга, то есть IP-адреса из доменов из «выгрузки». По цифрам видно, что мы по нескольким тысячам IP подкалибровались под мой резолвинг и под мое время (я постоянно опрашиваю домены), чтобы пики было видно, и начали писать: DIGITAL RESISTANCE.

Я привожу его, потому что на нем видно, как Роскомнадзор наконец-то начал чистить домены. На втором графике была большая надпись: «Воистину Попов!», потому что был День Радио. На момент генерации надписи «протухших» поддоменов в «выгрузке» было около 4 000, а к ноябрю стало стабильно, то есть Роскомнадзор проводил регулярные чистки. Там где ступенька, там они 2 домена уже нашли, а 2 еще нет, но они довели чистку до какого-то ума. Но, к сожалению, к времени выхода статьи количество доменов опять возросло — сейчас их 1538.

Кстати говоря, это единственный результат моей деятельности за несколько лет — реально начали хоть что-то делать!

Дело в том, что оборудование и программы фильтрации почему-то не хотят ходить строем: где-то тормозят, случаются сбои и ошибки. Кстати, об авариях и сбоях. Можно, например, использовать DNS-атаку — в простом случае сайт не упадет, потому что все нормально фильтруется, но качество его работы для пользователя будет очень низким. Чуть возрастает нагрузка, и качество обслуживания становится никаким. Можно так скажем «полудедосить» сайты, чтобы снизить качество их работы.

Владелец сайта Motobratan.ru был в отпуске и сказал, что ему все равно. Например, прошлым летом у Ростелекома в нескольких регионах фильтр выдавал почему-то один чанк HTTP протокола неправильно, и соответственно на экран валился мусор. Сайт все выходные так проработал, пока в понедельник с утра инженер не пришел и не починил.

Проблемы провайдера

По-хорошему должен быть регламент техобслуживания на случай, если:

  • не работает сервис «выгрузок»;
  • произошла авария на каналах связи, «выгрузку» невозможно получить;
  • сломались фильтры;
  • фильтры на профилактике.

Но, нет — это все штраф. Тут пока есть читкод, но боюсь, скоро он перестанет работать. Провайдеры в таких случаях на основе своего экзистенциального опыта выключают «Ревизора». Если вы выключили «Ревизора», вам звонит Роскомнадзор, вы говорите: «Ой, он сломался, сейчас чиним!» Но у вас есть небольшой запас времени между выключением «Ревизора» и звонком Роскомнадзора, и еще чуть-чуть на починку. За это время можно спокойно без штрафов провести какие-то профилактические работы.

Кстати говоря, когда была авария на ТТК, многие просто выключили фильтрацию и «Ревизора», на всякий случай.

Фантазии

Любимая фантазия о том, что с этим всем можно сделать, — белые списки. Но есть но:

  • Критерии включения в белые списки.
  • Система взаимодействия — поддержка у Роскомнадзора не очень хорошая, можно представить, во что это превратится.
  • В облаках как работать — писать заявку на каждую виртуалку? Например, Kubernetes хочет создать ноду, и вы пишите заявку на внесение ее в белый список — привет Continuous Integration!

Следующий вариант — волшебный DPI, который нам сейчас продадут китайцы, и он будет работать. Но чудес не бывает, производительность у DPI совсем не волшебная. Во-вторых, когда фильтруется что-то сложное, нужно хранить состояния. Но DPI не резиновый и, например, может попасть под специальные атаки на DPI, которые будут просто его класть. Обычные сбои естественно тоже будут. Кто жил под DPI в закрытых интернетах, прекрасно знает, что они работают так себе.

Еще одна фантазия — давайте сделаем единый государственный DNS для резолвинга, и все будет нормально.

  • Это трудоёмкая задача, потому что DNS легко сделать себе в офис, а для публичного использования — не очень.
  • Это не решает проблему фаз при проверке, о которой я говорил выше. Эта проблема, собственно, вообще никак не будет решаться.
  • Я не понимаю, зачем держать государственный DNS, если легче держать «выгрузку» актуальной.

И в конце развлекательный вопрос: можно ли заблокировать Telegram?

Заблокировать Telegram можно, если немного изменить нормативную базу, законы, поставить волшебные DPI и пренебречь сопутствующим ущербом. Отвечу на полном серьезе, без иронии: да. Мы, это видим на примере Ирана, в котором заблокированы тысячи сайтов, но зато относительно хорошо блокируется и Telegram.

Надеемся, этот рассказ помог составить общее представление о технической составляющей блокировок интернета в России.

Некоторые подробности можно узнать из  ответов на вопросы после доклада, на сайте Филиппа Кулина, в Telegram-канале о регулировании интернета в России @usher2 и в профиле schors

Узнать о новых материалах и открытых видео удобно из рассылки — она нечастая, и исключительно по делу. Эта статья основана на одном из вызвавших самый большой интерес слушателей докладе HighLoad++ 2018. Например, её получатели точно в курсе, что вовсю идет заявочная кампания на апрельский Saint HighLoad++.


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

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Дата-центры на выбор: Лондон, Москва, Цюрих, Санкт-Петербург

Отчасти санкции, отчасти рост технологического бизнеса, отчасти рост дохода этого самого бизнеса сформировали в России условия для развития коммерческих ЦОД. Если раньше можно было горько усмехнуться над SLA, ждать пока встанет интернет-магазин на лежащем сервере, фактически доверять провайдеру «в тёмную», ...

Подборка: 4 полезных сервиса для потенциальных иммигрантов в США, Европу и другие страны

Я решил собрать в одном месте список онлайн-сервисов, которые будут полезны тем, кто всерьез задумался об иммиграции. Тема переезда в Европу, США или другие приятные регионы мира довольно часто поднимается на Хабре. Для статьи я отобрал четыре проекта. На удивление, ...