Pull to refresh

Создаём прокси-чекер стоимостью 100 миллионов за пару дней

Reading time 5 min
Views 15K
Каждый день в сети закипают страсти вокруг относительно популярного IT-ведомства «Роскомнадзор». Недавно наткнулся на одну не сказать, что свежую, но и не достаточно забытую статью о планах на будущее. Суть простая: РКН объявил тендер на разработку «системы контроля за блокировкой сайтов» далее именуемой как «Ревизор».

Чтобы особо не углубляться в суть задачи, вырву из статьи фрагмент интервью с руководителем ведомства Александром Жаровым:

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

Непосредственно суть задачи (цитата):

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

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

В принципе задача предельно ясна, попробуем найти «оптимальное решение»:

Давайте гипотетически предположим, что так называемый «Ревизор» — это обычный прокси-чекер, который по определенному прокси получает ответ сервера. Что нам потребуется:

  1. Список всех провайдеров
  2. Около 10 прокси от каждого провайдера
  3. Список запрещённых страниц (информация из реестра)

Имея эти входные данные, мы можем создать прокси-чекер, который будет работать в 3-этапа:

  1. Выгрузка списка запрещённых страниц из реестра (их не так много, 12 000 по неофициальным данным)
  2. Получение ответа сервера по каждому из IP адресов всех провайдеров
  3. Формирование/отправка отчёта

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

К тому же большинство дата-центров по каждому из провайдеров используют одну и ту же систему обработки реестра, и в этом случае провайдер либо целиком отвечает требованиям Роскомнадзора, либо где-то произошёл недочет, и дата-центр вовсе значения не имеет, я думаю проблема будет глобального масштаба по всему провайдеру в целом.

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

Это сложное, но достаточно примитивное решение. Ждать, пока провайдеры сформируют для РКН список актуальных прокси-серверов, не есть выход. Но, судя по тому, что «на первоначальном этапе на линиях основных операторов связи будет установлено 700 зондов», обязать провайдера дать прокси — это самая маленькая из всех бед!

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

Ну что же, представим, что у нас есть список всех доступных прокси из России. К примеру, их у нас 100 000. Нам потребуются 4-этапа:

  1. Проверка прокси на определение провайдера
  2. Формирование списка уникальных провайдеров
  3. Проверка ответа страниц из реестра по каждому из прокси
  4. Формирование всё того же отчёта

Непонятным может показаться только первый пункт. По нему я дам развернутый ответ. Имея список доступных проксей, мы без труда сможем по hostname каждого ip адреса идентифицировать того или иного провайдера, к тому же такие решения уже доступны. К примеру, если вы откроете сервис 2ip, то увидите информацию о вашем IP адресе:

image

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

P.S Ну и в конце концов, использование прокси это ну совсем «колхозный метод», он лишь показывает возможность реализации. Но и не стоит забывать в большинстве случаев доступные прокси — это чей-то ботнет, и естественно РКН ну ни как не может использовать список прокси.

Фактически Роскомнадзор запланировал куда более дорогостоящий и менее оптимальный вариант реализации задачи. Хотя, если вопрос актуальности исполнения блокировки сайтов стоит настолько остро, надежнее было бы всё же обязать провайдера выделять несколько проксей из своих дата-центров, чтобы актуально проверять отклики по тому или иному ресурсу из реестра запрещённых сайтов. К тому же центр обработки реестра никак не привязан к дата-центру, и алгоритм обработки реестра скорее всего глобален для всего провайдера. А значит осечки будут тоже глобальными, а значит и ограничиться можно списком провайдеров без дополнительных заморочек по каждому дата-центру.

Такое решение выглядит достаточно быстрым и надёжным, а самое главное изобретать велосипед и называть его зондом ни к чему. К тому же от провайдера потребуется то или иное участие в реализации любого из вариантов. Так проще поддерживать актуальность алгоритма на своей стороне, нежели контролировать что-то на стороне провайдера, а для реализации много не потребуется.
Tags:
Hubs:
0
Comments 26
Comments Comments 26

Articles