PhantomTLT

В статье забыли упомянуть http://cyberfilter.ru

Показать пользователю сообщение (с неправильным сертификатом) не проблема. Но, это так же может заставить пользователя волноваться. По SNI - спасибо за идею, подумаем как реализовать.

Понятно. А с https как поступаете, в РКН такое есть? Так же как все - блокируем по IP. Вернее IP:443

Со списком Минюста не боремся. У клиента есть возможность вести в системе свои реестры. Они туда вносят решения судов, которые получили в свой адрес. У нас же в планах сделать список Минюста доп. опцией, разумеется только те записи, где URL/домен указаны корректно.

РКН вносит в реестр и IP и домен/хост и URL. Однако при наличии возможности блокировки по URL вы должны блокировать по URL, если нет возможности - тогда домен или IP. Мы консультировались с РКН (московским) на эту тему. Собственно говоря мы и даем такую возможность, за смешные деньги и без начальных кап. затрат. Заодно возможность обхода блокировок по IP Ростелекома. Если бы Ростелеком не занимался ерундой по отношению к операторам связи, то наше решение было бы несколько иным. Кстати, DPI если у вас один из каналов через Ростелеком - абсолютно бесполезен. Опять же, если вам не мешает серый волк Ростелеком и вы не хотите гонять трафик через туннель, но при этом хотите фильтровать по URL, то мы можем предоставить доступ к API - установите у себя прокси, да и все.

3. Не на наш, а на DNS оператора связи, который забирает у нас сформированную RPZ зону. Что такое GCC - если честно, не знаю. 4. Чтобы использовать прокси, нужно знать его IP и он должен быть открытым. Если оператор связи использует прокси (такие еще есть ?), то он сообщает его абоненту и такой прокси не является проблемой. Если абонент сам нашел прокси в инете и начал его использовать для обхода ограничений, то в чем виноват оператор связи ? Чем это отличается от использования абонентом стороннего VPN ? Если у вас настолько невменяемая прокуратура - запретите использование прокси совсем. Хитрый абонент по любому обойдет хоть DPI, хоть не DPI. Можно сделать банальный туннель через SSH и вряд ли вы его как либо заблокируете. У любого решения есть плюсы и минусы. Любое решение можно обойти так или иначе. У нас ведь не китайский фаревол. В конце концов какая цель у вашего бизнеса - усложнить жизнь абонентам или выполняя требования законодательства зарабатывать деньги ?

1-2. Интересы пользователей везде практически одинаковые. Альтернативы - блокировать все без разбора по IP, покупать DPI, строить свой велосипед. В любом случае выбор за вами. 3. http://en.wikipedia.org/wiki/Response_policy_zone. Будет возвращен адрес фильтра. 4. Использование HTTP-прокси, SOCKS-прокси, VPN и т.д. - это использование пользователем СПЕЦИАЛЬНЫХ мер, для обхода фильтрации, которую вы, как оператор, организовали для соблюдения норм законадательства. По сути это тоже самое, что использовать монтировку/отмычку для вскрытия замка на вашей двери. а зачем трафик ОТ гугла тоже идет через вашу систему? или вы проксируете запросы? Проксируем, чтобы вывести сообщение о блокировке ресурса. Алтернатива - слать RST, т.е. обрывать соединение. Это на наш взгляд не корректно по отношению к пользователю и к техподдержке оператора.

1. Трафик гугла (от автономной системы гугла) всего 3% от общего трафика. Это по статистике одного из весьма не маленьких провайдеров. 2. Что касается трафика, то по опыту могу сказать - реестр РКН + решения местных судов (вот уж кто все без разбора пытается блокировать) - это примерно 1/1000 от общего трафика провайдера. Да, именно так - с 30 гигабит, 30 мегабит на фильтрацию. 3. По запросам DNS - разумеется все предусмотрено. Для этого используется дублирующий механизм DNS RPZ - абонент все равно попадет на фильтр. Можно использовать только DNS RPZ, но тогда выпадут абоненты которые используют собственный DNS или какой-нибудь 8.8.8.8. Но опять же, оператор может завернуть все DNS запросы на свой сервер. Было бы желание. 4. VPN/аномайзеры/Opera+Turbo разумеется никак не фильтруется. Так же как и в других решениях. У нас нет задачи построить китайский фаревол.

Если заблокируют ролик на ютубе, то морда ютуба завернется на фильтр. Отфильтруется один ролик. Все прожуется, т.к. контент у гугла находится на совершенно других серверах. IP определяются периодическими DNS-запросами

Если это сайт расположенный на "сайтах google" (кажется так этот сервис у гугла называется), то - да, трафик для этого хоста завернется в туннель. На другом конце туннеля, он будет обработан и будет отфильтрован только этот сайт/URL.

1. Прилетают маршруты /32 сайтов из реестров. Приоритет (local preference) вы устанавливаете у себя (если хотите). Со стороны сервиса устанавливается только bgp community по принадлежности к тому или иному реестру. 2. Прописывание сторонних DNS абоненту не поможет, т.к. трафик на IP адреса ресурсов из реестров завернется в туннель и уйдет в сервис.

1. 3500 минимальный тарифный план. 2. Чем ИП отличается от ООО с уставным капиталом в 10 тыс. руб ? 3. Не понятна схема работы ? Задавайте вопросы, отвечу.

Облачный сервис для фильтрации по реестрам Роскомнадзора - http://cyberfilter.ru Для подключения не нужны никакие затраты на покупку оборудования. Достаточно всего лишь настроить туннель + BGP.

Оно у вас случайно теперь не в userspace работает ? Исходники pptpd-1.3.3 в комплекте accel pptpd патченные на предмет использования accel...

Напротив. Идея жизнеспособна. Но реализация немного подвела :) Я развил идею. Сделал распаралеливание для каждого пользователя. Т.е. пакеты от/к каждому пользователю идут только через определенный CPU (на каждый CPU по две очереди - rx & tx). Резулультат ниже. Это для MAX_CPU=3, т.е. обработкой pptp занимаются первые три ядра. На четвертов висят обе сетевушки. top - 16:28:53 up 1:05, 1482 users, load average: 6.37, 6.39, 6.13 Tasks: 3062 total, 1 running, 3061 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 2.2%sy, 0.0%ni, 89.7%id, 0.0%wa, 0.0%hi, 8.1%si, 0.0%st Cpu1 : 2.8%us, 1.6%sy, 0.0%ni, 87.9%id, 0.0%wa, 0.0%hi, 7.8%si, 0.0%st Cpu2 : 0.0%us, 2.5%sy, 0.0%ni, 87.0%id, 0.0%wa, 0.0%hi, 10.6%si, 0.0%st Cpu3 : 0.9%us, 5.9%sy, 0.0%ni, 47.8%id, 0.0%wa, 5.3%hi, 40.1%si, 0.0%st Из этого, на мой взгляд, можно сделать два основных вывода: 1. Идея впролне работоспособна. Нагрузка распаралеливается и достаточно ровно. 2. Видимо Cpu3 страдает из-за шейперов, маркировки и т.д. Нужна оптимизация. И дело не столько в accel-pptp, сколько именно в шейперах и прочей ерунде, что стандартно навешано у оператора. Хотя, видимо. Схема с правильными сетевушками (с количеством очередей=количеству CPU Core) - более правильная.