Чтобы особо не углубляться в суть задачи, вырву из статьи фрагмент интервью с руководителем ведомства Александром Жаровым:
«В конкурсе участвуют четыре компании. Требования, несмотря на то, что они простые, достаточно жесткие. Победит тот, кто предложит наименьшую цену и оптимальное решение. Первоначальная цена контракта — 100 млн рублей». По словам главы надзорного ведомства, система «Ревизор» позволит в реальном времени контролировать эффективность блокировки запрещенных сайтов.
Непосредственно суть задачи (цитата):
Суть действия зонда или программы в том, что она, как обычный пользователь, но быстрее простого пользователя, высылает большое количество запросов по всему перечню запрещенных ресурсов и по количеству ответов способно сообщить инспектору Роскомнадзора, заблокирован ли сайт.
Предположим, что нас интересует только конечный результат: инспектор РКН хочет получить информацию о том, заблокирован ли сайт по каждому из провайдеров.
В принципе задача предельно ясна, попробуем найти «оптимальное решение»:
Давайте гипотетически предположим, что так называемый «Ревизор» — это обычный прокси-чекер, который по определенному прокси получает ответ сервера. Что нам потребуется:
- Список всех провайдеров
- Около 10 прокси от каждого провайдера
- Список запрещённых страниц (информация из реестра)
Имея эти входные данные, мы можем создать прокси-чекер, который будет работать в 3-этапа:
- Выгрузка списка запрещённых страниц из реестра (их не так много, 12 000 по неофициальным данным)
- Получение ответа сервера по каждому из IP адресов всех провайдеров
- Формирование/отправка отчёта
Предположим мы имеем актуальный список всех провайдеров, каждый провайдер обязуется выделять по 1 прокси из всех своих региональных дата-центров. Достаточно в циклическом порядке поставить опрос всего списка из реестра запрещённых страниц, по каждому из проксей провайдера, и получать ответ по каждому региональному дата-центру. В отчёте мы всегда будем получать актуальную информацию, что тот или иной документ отдает правильный ответ, и документ из реестра заблокирован, ну а отрицательные ответы публиковать в отчёт, где наглядно будет видно какой провайдер и по какому дата-центру не ограничил доступ к запрещённому ресурсу. Ну и на базе сформированного отчёта можно уже фантазировать. Инспектор будет видеть актуальную информацию — это очевидно, но на этом можно не ограничиваться. Если обязать провайдера отдавать не только список проксей по каждому дата-центру, но и параллельно отдавать контактный e-mail уполномоченного ведомства, отвечающего за обработку реестра, можно в автоматическом режиме информировать каждого провайдера о несоблюдении технических требований.
К тому же большинство дата-центров по каждому из провайдеров используют одну и ту же систему обработки реестра, и в этом случае провайдер либо целиком отвечает требованиям Роскомнадзора, либо где-то произошёл недочет, и дата-центр вовсе значения не имеет, я думаю проблема будет глобального масштаба по всему провайдеру в целом.
Тем не менее. Обязать каждого провайдера отдавать прокси выглядит слишком глобально, хотя и примитивно, возможно, в этом и заключается задача Ревизора — обойти эту необходимость. Но если говорить об оптимизации трудозатрат, инспектору не особо-то и поможет этот список, поэтому в любом случае нужно информировать провайдера через отчёт. Соответственно, если поддерживать актуальную информацию по каждому из провайдеров, можно отправлять сигнал соответствующему ведомству на ликвидацию проблемы.
Это сложное, но достаточно примитивное решение. Ждать, пока провайдеры сформируют для РКН список актуальных прокси-серверов, не есть выход. Но, судя по тому, что «на первоначальном этапе на линиях основных операторов связи будет установлено 700 зондов», обязать провайдера дать прокси — это самая маленькая из всех бед!
Ну а теперь давайте вернемся к задаче и рассмотрим «колхозный», но быстрый и еще более примитивный способ получение желаемого результата. Опять же, напомню цитату из поставленной задачи: «инспектор РКН хочет получить информацию о том, заблокирован ли сайт по каждому из провайдеров».
Ну что же, представим, что у нас есть список всех доступных прокси из России. К примеру, их у нас 100 000. Нам потребуются 4-этапа:
- Проверка прокси на определение провайдера
- Формирование списка уникальных провайдеров
- Проверка ответа страниц из реестра по каждому из прокси
- Формирование всё того же отчёта
Непонятным может показаться только первый пункт. По нему я дам развернутый ответ. Имея список доступных проксей, мы без труда сможем по hostname каждого ip адреса идентифицировать того или иного провайдера, к тому же такие решения уже доступны. К примеру, если вы откроете сервис 2ip, то увидите информацию о вашем IP адресе:
Как видите, определить по IP-адресу вашего провайдера не сложно. Соответственно, даже используя список актуальных прокси серверов, можно в 2 этапа провести проверку на опрос каждого прокси на принадлежность к провайдеру, сгруппировать прокси по маркировке всех повторяющихся провайдеров, ну и провести опрос реестра по максимально возможному уникальному списку провайдеров, где уникальностью будет являться принадлежность группы прокси к тому или иному провайдеру. В зависимости от популярности провайдера будет и расширенная группа прокси, но ведь прогнать через каждый прокси все 12 000 запрещенных страниц, и если проблема с популярными провайдерами решаема (так как у популярного провайдера и группа прокси будет сформирована немаленькая, и равномерно распределить ответы по всем 12 000 документам будет вполне реально), то что же делать со списком тех провайдеров, где определён дай бог только один живой прокси? Не прогонять же через него весь список из 12 000 страниц.
P.S Ну и в конце концов, использование прокси это ну совсем «колхозный метод», он лишь показывает возможность реализации. Но и не стоит забывать в большинстве случаев доступные прокси — это чей-то ботнет, и естественно РКН ну ни как не может использовать список прокси.
Фактически Роскомнадзор запланировал куда более дорогостоящий и менее оптимальный вариант реализации задачи. Хотя, если вопрос актуальности исполнения блокировки сайтов стоит настолько остро, надежнее было бы всё же обязать провайдера выделять несколько проксей из своих дата-центров, чтобы актуально проверять отклики по тому или иному ресурсу из реестра запрещённых сайтов. К тому же центр обработки реестра никак не привязан к дата-центру, и алгоритм обработки реестра скорее всего глобален для всего провайдера. А значит осечки будут тоже глобальными, а значит и ограничиться можно списком провайдеров без дополнительных заморочек по каждому дата-центру.
Такое решение выглядит достаточно быстрым и надёжным, а самое главное изобретать велосипед и называть его зондом ни к чему. К тому же от провайдера потребуется то или иное участие в реализации любого из вариантов. Так проще поддерживать актуальность алгоритма на своей стороне, нежели контролировать что-то на стороне провайдера, а для реализации много не потребуется.
Комментарии (26)
BupycNet
14.10.2015 15:40Ну вот, теперь еще большая часть суммы будем распилена. Вы им только что подарили бесплатное решение. Любая компания теперь сможет взять свою долю, сделать откат и за сутки выкатить бесплатное решение, получив неплохой доход.
Temych
14.10.2015 16:19Если что, то полный текст ТЗ по реализации этой системы можно посмотреть тут.
Ну и сам конкурс уже завершен, так что автор может попытаться обратиться со своими идеями минимизации расходов компании-победителю))
Но не думаю, что цель задуманной реализации является как-то что-то минимизировать.
Dm4k
14.10.2015 17:05А объясните пожалуйста, если обладаете такой информацией, почему выиграла не самая низкая по цене заявка?
И зачем делать заявку с ценой выше предельной?
danSamara
14.10.2015 19:24+1Цена — не конечный фактор, может оцениваться ещё много параметров — документация, похожие проекты, величина компании, знакомства :) Но здесь разницы в цене практически нет, обе — дешевле начальной цены и победившая всего на полпроцента выше самой дешёвой.
Выше предельной делают чтобы не выбрали — для толпы. Меньше трёх заявок совсем палевно делать.
Temych
14.10.2015 20:18К сожалению, я не входил в состав комиссии, которая принимала решение о победителе по этому конкурсу)
Но предположу, что один из участников подал цену выше либо:
а) по дурости
б) специально слив себя, чтобы выиграл другой — по взаимной договоренности
в) подал первым и думал — такая цена прокатит, если больше никто не примет участие в конкурсе.
Насчет победы не минимальной по цене заявки — комиссия принимает решение, отталкиваясь не только от цены, но сверяя и другие параметры конкурсантов.danSamara
14.10.2015 20:49а) и в) — для лота в 100 лямов? :)
Там же не просто галочка ставиться — «я вася пукин, сделаю за 100500, отвечаю!». Надо подготовить документы и обосновать цены. Чем больше лот — тем больше «сопроводиловка».Temych
14.10.2015 21:41Конечно, но есть и разные игры и такое понятие, как «откаты».
Но безусловно — наличие цены превосходящей значительно максимально заявленную — удивляет и меня.
Я лишь обозначил те варианты, которые как я вижу возможны, что не исключает и варианты под литерами г), д) и даже xyz)
Кстати, косяки с заявками — это очень частая проблема на конкурсах, в т.ч. и госзакупок, человеческий фактор никто не отменял.
Sap_ru
15.10.2015 12:55+1Липовый участник тендера — чтобы мог участвовать, но не мог победить ни в каком случае по формальным признакам (цена превышает максимальную — участвовать можно, а победить нельзя).
Наличие такого участника — 100% показатель распильной схемы.
Более того, очень маленькая разница между победителем и вторым местом наводит на нехорошие мысли — либо победителю «слили» заявку проигравшего, либо задним числом подправили заявку победителя.danSamara
16.10.2015 00:30либо победителю «слили» заявку проигравшего, либо задним числом подправили заявку победителя.
Не сходится — тогда у победителя сумма была бы чуть меньше — для 100% гарантии.Sap_ru
17.10.2015 02:40Так у победителя и суммы и есть совсем на чуть-чуть меньше чем у второго места. Такая маленькая разница означает, что победитель знал о сумме второго участника.
danSamara
17.10.2015 10:37Нет, чуть больше:
Заявка №3537366 (Победитель) — ООО «МФИ Софт» — 84 183 357
Заявка №3537379 — ООО «Веллинк» — 83 733 356
Заявка №3536303 — ЗАО «Ай-Теко» — 138 538 600
Denisov_pro
15.10.2015 21:51Вот бред развели! За распил нет и доли сомнения. Роскомнадзор самое бестолковое ведомство, которое только могло возникнуть. А то, что гос бюджет тонко распилили я думаю это очевидно, все же хабра сообщество людей не далеких от технологического прогресса. Представленный тендер ни что иное, как нажива для «своих». Одно дело, когда тендер на разработку электронного правительства, другое, когда на прокси-чекер.
navion
16.10.2015 10:50А никто не встречал готового решения для обхода прокси на уровне организации?
Можно запихнуть все 12 тысяч адресов в ACL на роутере и пускать трафик до них через VPN в облаке, но вылезают нюансы реализации — как обновлять список и насколько просядет производительность устройства?
Caravus
О чём эта статья? Я честно прочитал 90% текста (и даже посмотрел картинку), но так и не понял причин побудивших написать эту стену текста.
danSamara
Автор хочет немного из тех 100 миллионов.
Denisov_pro
Автор не программист :), просто есть личная неприязнь к ведомству. Хотелось бы описать как тонко распиливаются бюджеты. За 100 млн тендер на изготовление чекалки.
danSamara
Я тоже не люблю данное ведомство и распилы, но это не просто «чекалка». Во-первых там есть информация про 10000 «агентов» — это, как я понимаю, автономные мини-компы, которые будут установлены у операторов. Если скромно оценить каждого агента примерно в 30к (железо, обучение, поддержка железа, поддержка софта и т.д.), то уже получается 30 миллионов.
Не стоит подобные задачи оценивать как «чекер, который я напишу за два дня». Напишите конечно. Но не разработаете решение для всей России с поднятием инфраструктуры, наймом людей, написанием кучи бумаг и т.д.
Распил-то конечно будет (вернее уже был — судя по результатам тендера), но не такой масштабный, как видится на первый взгляд.
Sap_ru
Скорее всего агентом будет кривое ПО под какую-нибудь винду, а уж как и где его размещать — головная боль провайдеров.
danSamara
Вряд ли. Это тот случай, когда результат важен — заказчику нужна реально работающая система. Надо же бороться с порнографией, суицидами, наркоманией и терроризмом.
navion
СОРМ провайдеров заставили самих покупать, думаете тут будет по-другому?
danSamara
Уверен. Заставлять долго, делать самим — быстро. Цензура важнее ловли преступников и слежки, поэтому надо быстро.
navion
Штраф за просрочку существенно ускоряет внедрение. Могут даже пообещать покрыть затраты операторов, как в прошлый раз.
Denisov_pro
Причины сугубо личного характера, дискуссия с другом, можно ли уложиться в пару дней или нет.