Технические аспекты блокировки интернета в России. Проблемы и перспективы
Начнем сразу с дисклеймера: ниже принципиально не будет политических вопросов. Административные и юридические вопросы тоже будем обходить настолько, насколько сможем, чтобы полностью не вырывать техническую часть из остальных плоскостей.
Блокировки интернета в России уже есть — это данность, с которой мы живем и должны жить дальше. А раз так, нужно разбираться, как это устроено технически, что может и не может провайдер. Филипп Кулин (schors) давно начал собирать информацию по этому поводу, участвовал в нормативной работе, ходил на разные совещания. В итоге сейчас больше него о блокировках в России знает только Роскомнадзор, но это не точно. Под катом краткая сводка актуального состояния дел.
О спикере: Филипп Кулин (schors) генеральный директор ООО «Дремучий лес» — небольшого российского хостера, занимающегося в основном shared-хостингом.
Сплошной клубок проблем
Казалось бы, есть блокировки и есть. Не нравятся они нам, но, может быть, ничего плохого в них нет?
На самом деле, блокировки — это сплошной клубок проблем.
Сопутствующий ущерб — самая большая проблема блокировок. Самый яркий пример, иллюстрирующий это, произошел в апреле 2018 года, когда были заблокированы большие блоки IP-адресов облачных сервисов, соответственно, многие сервисы не работали и понесли большой ущерб.
Волатильность нормативов и практик, которые все время изменяются. Год назад этот рассказ был бы абсолютно другим, а два года назад он, скорее всего, противоречил бы сегодняшнему. Через год снова все будет по-другому. Сегодня это так, через месяц — немножко не так, а через полгода вообще не так. За этим надо следить, но и успевать работать тоже надо.
Блокировки трудно диагностировать. Если какой-то ресурс попал в блокировку именно по реестру — это самый простой случай. В случаях, которые мы рассмотрим дальше, отличить реальную блокировку от технических проблем достаточно сложно. Яркий пример — в октябре у Яндекса падал DNS часов на пять, за это время многие успели решить, что это блокировка Роскомнадзора. Определить точно, действительно, трудно, а ситуации такие уже бывали, поэтому люди сразу думают о блокировке.
Невозможно предсказать, когда вас заблокируют и заблокируют ли вообще. Вы спокойно работаете, а работа у вас вдруг закончилась.
Рассчитать риски совершенно невозможно, потому что, может быть, отвалится какой-то виджет на сайте, про который вы уже и забыли, а может и весь бизнес попасть под удар. Очень хороший пример непредсказуемости рисков — это случай Битрикс24. В марте они очень быстро перенесли свои сервисы в Amazon. В этом же месяце в сеть утек документ, который правда возможно был фейковый, в котором были прописаны большие подсети Amazon. Тем не менее Битрикс24 как-то на него отреагировали и избежали проблем в апреле, когда сервисы Amazon действительно были заблокированы.
Уверяю, большинству из вас так не повезет! Такие документы не будут по счастливой случайности утекать вам в руки. Когда ваш бизнес закончится, вы узнаете об этом постфактум.
В простых случаях известно, почему ваш сайт заблокировали. Например, на форуме разместили информацию, которую какой-то суд признал запрещенной, а вы не успели среагировать. Но общение с надзорным органом имеет неприемлемые сроки — например, сутки. В интернете за это время вы можете потерять пятую часть бизнеса.
Все это приводит к некой безысходности. Можно с иронией рассуждать над, например, Дэвидом Хомаком и блокировкой Лурка. Но совсем другое дело, когда это происходит с вами, как один раз произошло со мной. Клиент указал IP-адреса моих серверов у домена, которым я не управлял — я сижу, а телефон просто не умолкает. Клиенты говорят, что они уходят, требуют вернуть деньги, а я сделать ничего не могу! И никто не может мне в этом помочь. Это реально ощущение полной безысходности.
Группы риска
Блокировки касаются:
- Владельцев сайтов и сервисов, которых, в том числе, могут заблокировать по ошибке. Или могут признать какую-то информацию запрещенной.
- Пользователей сервисов блокировки тоже касаются. То, что ваш сайт заблокировали, касается в первую очередь вас. Но ведь есть люди, которые этим сайтом или сервисом пользовались.
- Хостеров и провайдеров, которые находятся между двумя огнями. Потому что от них требуется и работающие сервисы, и выполнение требований надзорного органа, который грозит штрафами. Напомню, что штрафы от 50 до 100 тысяч рублей за протокол. Таких протоколов, например, за месяц может быть много и суммы получаются очень существенные.
Принцип работы блокировок
Сначала кратко обсудим, как происходит блокировка, чтобы понимать полную картину.
- Федеральные органы исполнительной власти или суд принимают решение о запрете какой-либо информации по каким-то своим причинам.
- Отправляют информацию в Роскомнадзор, который обязательно вносит запись в реестр запрещенных сайтов.
- Дальше проходят некоторые внутренние процедуры (их тоже много — целую лекцию можно читать), в результате которых Роскомнадзор может принять решение о блокировке и внести сайт в так называемую «выгрузку» — технический файл, который направляется провайдерам.
- Провайдеры по этому файлу осуществляют ограничение.
- Проверка провайдеров, которая уже два года происходит автоматически.
Важно понимать, что трафик фильтруется каждым провайдером. То есть не где-то на трансграничных маршрутизаторах или государственным фильтром, а каждый провайдер ставит себе фильтр между интернетом и абонентами в каждой своей подсети. На схеме выше устройство проверки рядом с абонентами, потому что оно изображает из себя абонента — это важно.
Инструменты фильтрации
Провайдеры могут покупать фильтрованный трафик у вышестоящего провайдера. Но тут есть проблема — покупая трафик у вышестоящего провайдера, провайдер-покупатель не может определить техническая проблема или блокировка. Он не имеет никакого инструмента, потому что получает уже порезанный трафик, и это не очень хорошо сказывается на его бизнесе.
Либо можно использовать:
- специальные комплексные коммерческие решения;
- свободно распространяемые решения с открытым исходным кодом (на данный момент такой проект один);
- свой «колхоз».
Там нет никакого рокетсайнс, и основные проблемы совсем не в том, чтобы написать программу.
Есть следующие варианты реализации.
Например, у вас есть небольшой канал в 100 Гбит, вы поставили фильтр в разрыв.
Некоторые зеркалируют трафик, но с зеркалированием трафика проблема в том, что работает это как бы на опережение. То есть фильтр пытается ответить быстрее нормального ответа, соответственно, если фильтр начал тормозить, — штрафы (напомню, 50–100 тысяч рублей).
Выборочная маршрутизация — когда трафик на IP-адреса, среди которых может быть что-то из «выгрузки», проходит через отдельный фильтр.
К сожалению, точных цифр нет, но судя по косвенным признакам и тестам, это сейчас самый распространенный способ фильтрации трафика.
Выборочная маршрутизация может дополняться тем, что наборы IP-адресов для фильтрации агрегируются в большую сторону. То есть блокируется не просто несколько адресов, а вся сразу сеть /24 попадает на фильтр. Плюс у крупных провайдеров, например, в МТС, есть специальные службы безопасности, которые специально ищут блоки IP c риском, которые тоже попадают в фильтрацию.
Также выборочную маршрутизацию можно комбинировать с фильтрацией DNS-запросов. Это популярный метод, которым пользуется, например, Дом.ru.
Разберем поэтапно проблемы, которые все это приносит.
Принятие решения о блокировке
Роскомнадзор принимает решение — это сразу вызывает проблему связанную, так скажем, с организацией службы поддержки. В ряде случаев он должен уведомить владельца сайта или хостера, но при этом адресат уведомления не точен (он берется из публичных данных, а не все поддерживают актуальные адреса), уведомления теряются, открытой информации нет.
Из-за этого происходят всякие плохие вещи. Хостер или владелец сайта не может контролировать, какие запросы к нему ведутся, никакой открытой информации нет. Например, у Google есть база сайтов с вирусами, где вы можете себя зарегистрировать как автономную систему, как-то подтвердить, что вы автономная система, и действительно самому смотреть, какие сайты по мнению Google в вашей автономной системе распространяют «зловреды». С блокировками такого нет — вы рассчитываете только на то, что уведомление до вас дойдет, и вы его вовремя успеете прочитать.
Сроки взаимодействия с Роскомнадзором не соблюдаются, и в целом немного странные, несмотря на то что есть нормативы — за сутки отправить уведомление, за сутки ответить, за сутки принять решение. Когда вам приходит уведомление, а вы говорите, что у вас нет такой информации и просите разъяснений, то можете получить ответ и через несколько недель. А, может, вас заблокируют, а потом ответят, что информация у вас таки есть. Такие ситуации у меня были, но мало кто подает в суд — я вообще не знаю таких случаев.
Опять же, если пришло уведомление, вы не всегда можете понять, о чем оно. В большинстве случаев Роскомнадзор нормально описывает, что имеет в виду. Но даже в нашей практике микро-хостера было три случая, когда по описанию было непонятно, о какой информации речь. Я даже не знал, что клиенту написать — протоколы и тексты решения Роскомнадзор выдает только по суду, хотя у них есть такие документы.
Время применения «выгрузки»
Итак, решение приняли, провайдер скачал «выгрузку» и дальше должен с ней что-то сделать. Есть два варианта, насколько быстро: сутки или незамедлительно.
Важно, что сутки отведены и на блокировку ресурса, и на разблокировку, если вдруг принято решение о разблокировке. У многих это сделано, как ночные обновления коммутатора. Из моего опыта: не вовремя принял уведомление, ресурс заблокировали, вопрос решили, но сутки ждешь, пока разблокируют. А бизнес не ждет, появляются потери.
Но сейчас в нормативах очень часто звучит слово «незамедлительно», по устной договорённости это час. Но устная договоренность сегодня есть, а завтра ее нет. В основном формулировка «незамедлительно» сейчас касается прокурорских решений по экстремизму.
Чтобы понимать, как все фильтруется, надо знать, что находится внутри «выгрузки». Там список записей в XML одного из четырех типов по видам блокировки и реквизиты решения:
- URL (s) + домен + IP-адрес (а);
- Домен + IP-адрес (а);
- Домен с маской (*.example.com) + IP-адрес (а);
- IP-адрес (а) — понятно, есть адрес, и его полностью блокируем.
Чтобы было понятно, о каких цифрах идет речь, ниже статистика на 22 января 2019.
Важно: всего 139 тысяч записей, а самый популярный тип блокировки — это блокировка «по домену». Это HTTP и HTTPS протоколы.
Токсичность «выгрузки»
Перед тем, как блокировать ресурс, провайдер должен разобрать «выгрузку». С этим тоже есть проблемы. Я специально обратил внимание, что «выгрузка» — это не реестр, а некий технический документ, который провайдеру выдается для того, чтобы он на его основе принимал решения. Но несмотря на это, провайдеру приходится проводить очень большую обработку «выгрузки».
Например, в «выгрузке» есть избыточность, записи перекрывают друг друга. Если взять какой-то URL, это не значит, что не будет блокировки по домену, который содержится в этом URL. Таких сейчас не так много, правда, — чуть более трех тысяч.
В «выгрузке» содержатся URL с фрагментами (#) и сессиями. Это вообще ужас, потому что надо понимать, как проходит проверка.
Провайдер должен приводить «выгрузку» в нормальный вид, потому что в ней встречаются неправильные URL и домены. В основном сейчас встречаются только обратные слеши. Бывают пробелы, но их быстро убирают, а к обратным слешам почему-то особенная «любовь». Ну ладно, с обратными слешами вопрос решили, а если появится какой-нибудь плюсик? Поэтому всегда должен быть мониторинг, всегда надо что-то делать.
Еще раз обращаю внимание, что проблема провайдера — это наша проблема. Что делает провайдер? Мотивация в 100 тысяч рублей — это хорошая мотивация сделать так, чтобы вообще при любой проблеме, даже при любом намеке на проблему, рубить сразу, а потом разбираться.
Актуальность в «выгрузке» тех IP-адресов, которые не «блокировка по IP-адресам», а всех остальных (блокировки по домену, по URL, по маске) выглядит примерно так.
Буквально чуть больше половины актуально, а остальные полный фарш.
Проверка блокировок
Начну с конца.
Вся история реализации блокировок в России это история проверок этих блокировок.
Я не знаю, как заграницей, у нас это абсолютно точно именно история проверок. Все блокировки делаются не так, как написано, как их делать, а так, как проверят, потому что никому не нравится платить штрафы, особенно 100 тысяч.
До реестра запрещенных сайтов существовал список экстремистских материалов Минюста (он и сейчас существует, просто сейчас он в реестре, а тогда был отдельным) и прокурорские проверки блокировок по этому списку. Я микро-хостер и то умудрялся попадать на блокировку у меня таких ресурсов.
Существующие виды проверок:
- Выездные проверки (в основном МВД, ФСБ и прокуратура) — они редкие, но есть.
- АС «Ревизор» — любимая автоматизированная система, которая проверяет всех провайдеров.
«Ревизор» стоит за фильтром и полностью прикидывается абонентом. Но сам прибор ничего не делает, он получает задачи и отдает ответы в некий центр управления, т.е. это такой удаленный shell внутрь сети провайдера. Действует он очень похоже действует на RIPE Atlas.
Центр управления автоматизированной системы — это настоящий 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 представляет нужный людям сервис, именно как DNS, например, IP-адреса. При подделке 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, в результате чего у них целый вечер не работала оплата картами.
Вы думаете, что кто-нибудь что-нибудь сделал? 
14 марта 2018 год: другой вектор атаки, но тоже с «протухших» доменов. Кто-то купил 4 домена, получил контроль над 400 поддоменов, и залил туда 4 000 IP-адресов. У ТрансТелеКома, у которого по заверениям Роскомнадзора все в порядке, где-то на 600 тысячах переполнилась таблица на маршрутизаторах, и 20% сетей ТTK по всей стране прилегло.
Не прошло и года: 
Это график резолвинга, то есть IP-адреса из доменов из «выгрузки». 5 мая я говорю Леониду Евдокимову: «А не пошутить ли нам — не написать ли на графике что-нибудь морзянкой?» Через час он это сделал. По цифрам видно, что мы по нескольким тысячам IP подкалибровались под мой резолвинг и под мое время (я постоянно опрашиваю домены), чтобы пики было видно, и начали писать: DIGITAL RESISTANCE.
На втором графике была большая надпись: «Воистину Попов!», потому что был День Радио. Я привожу его, потому что на нем видно, как Роскомнадзор наконец-то начал чистить домены. Там где ступенька, там они 2 домена уже нашли, а 2 еще нет, но они довели чистку до какого-то ума. На момент генерации надписи «протухших» поддоменов в «выгрузке» было около 4 000, а к ноябрю стало стабильно, то есть Роскомнадзор проводил регулярные чистки. Но, к сожалению, к времени выхода статьи количество доменов опять возросло — сейчас их 1538.
Кстати говоря, это единственный результат моей деятельности за несколько лет — реально начали хоть что-то делать!
Кстати, об авариях и сбоях. Дело в том, что оборудование и программы фильтрации почему-то не хотят ходить строем: где-то тормозят, случаются сбои и ошибки. Чуть возрастает нагрузка, и качество обслуживания становится никаким. Можно, например, использовать DNS-атаку — в простом случае сайт не упадет, потому что все нормально фильтруется, но качество его работы для пользователя будет очень низким. Можно так скажем «полудедосить» сайты, чтобы снизить качество их работы.
Например, прошлым летом у Ростелекома в нескольких регионах фильтр выдавал почему-то один чанк HTTP протокола неправильно, и соответственно на экран валился мусор. Владелец сайта Motobratan.ru был в отпуске и сказал, что ему все равно. Сайт все выходные так проработал, пока в понедельник с утра инженер не пришел и не починил.
Проблемы провайдера
По-хорошему должен быть регламент техобслуживания на случай, если:
- не работает сервис «выгрузок»;
- произошла авария на каналах связи, «выгрузку» невозможно получить;
- сломались фильтры;
- фильтры на профилактике.
Но, нет — это все штраф. Тут пока есть читкод, но боюсь, скоро он перестанет работать. Провайдеры в таких случаях на основе своего экзистенциального опыта выключают «Ревизора». Если вы выключили «Ревизора», вам звонит Роскомнадзор, вы говорите: «Ой, он сломался, сейчас чиним!» Но у вас есть небольшой запас времени между выключением «Ревизора» и звонком Роскомнадзора, и еще чуть-чуть на починку. За это время можно спокойно без штрафов провести какие-то профилактические работы.
Кстати говоря, когда была авария на ТТК, многие просто выключили фильтрацию и «Ревизора», на всякий случай.
Фантазии
Любимая фантазия о том, что с этим всем можно сделать, — белые списки. Но есть но:
- Критерии включения в белые списки.
- Система взаимодействия — поддержка у Роскомнадзора не очень хорошая, можно представить, во что это превратится.
- В облаках как работать — писать заявку на каждую виртуалку? Например, Kubernetes хочет создать ноду, и вы пишите заявку на внесение ее в белый список — привет Continuous Integration!
Следующий вариант — волшебный DPI, который нам сейчас продадут китайцы, и он будет работать. Но чудес не бывает, производительность у DPI совсем не волшебная. Во-вторых, когда фильтруется что-то сложное, нужно хранить состояния. Но DPI не резиновый и, например, может попасть под специальные атаки на DPI, которые будут просто его класть. Обычные сбои естественно тоже будут. Кто жил под DPI в закрытых интернетах, прекрасно знает, что они работают так себе.
Еще одна фантазия — давайте сделаем единый государственный DNS для резолвинга, и все будет нормально.
- Это трудоёмкая задача, потому что DNS легко сделать себе в офис, а для публичного использования — не очень.
- Это не решает проблему фаз при проверке, о которой я говорил выше. Эта проблема, собственно, вообще никак не будет решаться.
- Я не понимаю, зачем держать государственный DNS, если легче держать «выгрузку» актуальной.
И в конце развлекательный вопрос: можно ли заблокировать Telegram?
Отвечу на полном серьезе, без иронии: да. Заблокировать Telegram можно, если немного изменить нормативную базу, законы, поставить волшебные DPI и пренебречь сопутствующим ущербом. Мы, это видим на примере Ирана, в котором заблокированы тысячи сайтов, но зато относительно хорошо блокируется и Telegram.
Надеемся, этот рассказ помог составить общее представление о технической составляющей блокировок интернета в России.
Некоторые подробности можно узнать из ответов на вопросы после доклада, на сайте Филиппа Кулина, в Telegram-канале о регулировании интернета в России @usher2 и в профиле schors
Эта статья основана на одном из вызвавших самый большой интерес слушателей докладе HighLoad++ 2018. Узнать о новых материалах и открытых видео удобно из рассылки — она нечастая, и исключительно по делу. Например, её получатели точно в курсе, что вовсю идет заявочная кампания на апрельский Saint HighLoad++.
