Всем привет! У нас очень хорошие новости. Случилось нечто невероятное, из-за этого мы увеличили мажорную версию Carbon Reductor. Это случается довольно редко, примерно раз в год. Что же случилось? Заинтригованы? Поехали! Читать далее
Carbon Reductor DPI
Релиз Carbon Reductor 5.9.5
Новые рекомендации Роскомнадзора
В процессе добавления поддержки новых рекомендаций Роскомнадзора по фильтрации трафика был произведен рефакторинг, исправлен в мелочах и ускорен, почти в 2 раза, скрипт разбора единого реестра запрещённых сайтов.
Carbon Reductor соответствовал рекомендациям Роскомнадзора и раньше, за исключением последнего пункта — для адресов без указанных URL / доменов фильтрация по IP осуществлялась только на нескольких портах, а не на всех, попавших в зеркало.
Исправления ошибок
После релиза новой обработки списков всплыло ещё несколько мелких недочетов, они были исправлены. Обработка списков стала занимать значительно меньше времени. Мы навели лоск в процессе первой установки Carbon Reductor, в отображении информации о регистрации, в меню и веб-интерфейсе, починили отображение списка заблокированных URL. Стало еще удобнее и приятнее. А еще диагностика больше не ругается на бриджи, созданные libvirt’ом.
Carbon Satellite
В прошлых версиях Carbon Reductor было много изменений, которые повлияли на работу Carbon Satellite (бесплатный софт для выгрузки запрещенного реестра) «из коробки». Недочеты не такие серьезные и уже исправлены, все работает в штатном режиме.
Также доведена до ума система проверки фильтрации с отчётами о её эффективности по почте.
Релиз Carbon Reductor 5.9.3
Выход версии 5.9.3 прошёл довольно быстро, тем не менее изменений с версии 5.8 было сделано очень много и ниже мы их опишем.
Новая обработка списков
Мы перешли на python в этой части и не жалеем по нескольким причинам:
- nosetests позволяют гораздо легче тестировать код
- код стал значительно чище
- предыдущая версия на bash становилась всё менее и менее понятной с каждой новой «фишкой»
В результате новая версия обработки сократила число адресов, добавленных в базу зря (чем меньше адресов добавлено, тем выше производительность поиска по ней).
В бонус получили более правильную логику работы с кириллицей и прочими своеобразными URL’ами.
HTTP URL-матчинг модуль
После того, как мы сделали первую версию обработки списков, остро всплыл один недостаток алгоритма матчинга URL, который раньше затыкался (не всегда удачно) на этапе обработки списков. Мы решили поступить правильно и навести в коде модуля ядра «красоту» и переработать его.
Использование cmocka
В самом начале, перед рефакторингом мы поняли, что наш старый костыль для проведения чего-то похожего на Unit-тесты модуля фильтрации (его часть можно использовать в userspace для тестов) ужасен и неудобен. Для перехода на эту замечательную либу для тестирования понадобилось всего 2-3 часа (включая хоть какую-то дружбу тестов с инструментами для разработки команды). Дальше расширить покрытие тестами было уже значительно легче, а с хорошими тестами и рефакторить код получалось куда проще.
Производительность
Если чистая производительность (без учёта влияния нагрузки на сетёвки и прохода по всему сетевому стэку) алгоритма предыдущей версии составляла около 800000 пакетов/сек на 1 ядро процессора ≈2.5-3GHz, то сейчас нам удалось выжать 1900000-2100000 пакетов.
Решение проблемы с //
Имеется такая дурацкая бага:
часть браузеров приводит к виду
а часть — нет. Эту проблему имеют многие другие DPI (провели небольшой опрос среди коллег, абсолютно все могут обходить заблокированные HTTP-URL просто добавив второй / в URL). В общем для Carbon Reductor теперь нет разницы, какое число слэшей поставлено в запросе.
В качестве бонуса — это сократило объём используемой Carbon Reductor памяти.
Чистка кода
Перед этой глобальной доработкой мы решили воспользоваться новым опытом, полученным за время разработки Carbon Reductor и привести в порядок весь код проекта. Он стал значительно понятнее и короче аж на 30%. Надеемся, что это позволит нам быстрее двигаться вперёд в будущем!
Исправления багов
Отображение заблокированных адресов в вебе
После добавления новой обработки списков, файл со всеми обработанными URL (http.load) содержит адреса в разных кодировках, из-за чего пока что имеется проблема с его отображением в вебке. В качестве временного workaround, по умолчанию теперь в списках отображается необработанный список Роскомнадзора — rkn.list.
Диагностика
Теперь диагностика проверяет 3 дополнительных источника проблем:
- неполная загрузка URL в ядро (с версии 5.9.3 — ещё и исправляет)
- старая версия веб-интерфейса (при неудачном стечении обстоятельств могла вызвать проблему со стартом самого reductor и не работала фильтрация)
- запуск более чем 1го экземпляра crond (обычно из-за того, что «pid-файлы лгут»). Автоматически это исправлять мы побоялись, но уведомление администратору придёт. В целом это довольно серьёзная ошибка, приводящая к дублированию периодических задач.
Резолв HTTPS
Значительно снижена нагрузка на CPU при запуске резолва, немного ускорена её работа (раньше полный резолв на пустой базе занимал около 1м 30с, сейчас около 55 секунд), а также немного выпрямлен код всей этой подсистемы.
Чего ждать в следующей версии
Двойной буфер для загрузки URL в ядро
Сама она уже написана, лежит в отдельной экспериментальной ветке, осталось только корректно добавить блокировки, но сейчас имеется большое число более приоритетных задач, так что в релизе появится ориентировочно в первой половине ноября.
Без блокировок вероятны (пусть и не столь сильно) kernel panic при переключении. Нам была бы очень полезна помощь в обкатке этой версии под большой нагрузкой.
Оптимизация скорости обработки списков
В версии 5.9.1 мы добились скорости около 1.3 сек для 15000 необработанных URL. К сожалению, реальный мир заставил исправлять ошибки и в 5.9.3 скорость упала почти до 8 секунд. Мы поработаем над этим.
На этом все, всем спасибо 
Блокировки сайтов — к чему стоит готовится и как обезопасить себя?
Здравствуйте, друзья! Решили поделиться с вами успехами по внедрению нашего замечательного фильтра трафика Carbon Reductor, а еще обсудить актуальные вопросы, поговорить о наболевшем. Начнем по порядку.
За 2 месяца Carbon Reductor’ом заинтересовались более 60 компаний. Мы растем и в планах сделать полную карту установок – она впечатляет! Разумеется, рост дается не легко, мы постоянно улучшаем продукт и вводим дополнительные фишки, которых нет у конкурентов. Сначала поведаем последние новости, потом расскажем еще немного про продукт. Читать далее
Релиз Carbon Reductor 5.8.1
Регистрация и активация
Теперь регистрация и активация производятся через хелпдеск. В случае неудачи — на ближайший месяц оставлен fallback режим. Это позволит нам продолжить развивать систему мониторинга и добавить много других удобных возможностей.
Читать далее
Релиз Carbon Reductor 5.7.5
Дождливое лето никак нас не смутило, у нас появилось больше времени на разработку, и мы выпускаем новую версию Carbon Reductor даже чуть раньше срока, потому как накопилось довольно много фишек. Надеемся, что мы сможем держать этот темп и дальше. Читать далее
Более 40 внедрений за 2 месяца
Всем привет! Мы подготовили отчет за 2 месяца, с радостью рапортуем вам об этом! За 2 последних месяца более 40 компаний стали нашими клиентами. Еще мы подготовили карту установок по городам. Посмотрите
Читать далее
Релиз Carbon Reductor 5.7.3
Здравствуйте! Готова новая версия фильтра трафика по спискам Роскомнадзора Carbon Reducotr. Предлагаем ознакомиться со списком изменений:
- Добавлена фильтрация ftp (по ip, только 21 порт)
В реестре появились ссылки на FTP, теперь Reductor способен блокировать к ним доступ по указанному IP адресу - Добавлен скрипт проверки отчётов РКН (check_rkn_report.sh)
При проверке утилита РКН позволяет дать отчет о незаблокированных адресах. Новая утилита может пройтись по этому списку и выдать максимум информации, которая известная Редуктору об этих URL, что помогает решить проблему с незаблокированными адресами - Диагностика проверяет состояние кэша резолва https
- Улучшен вывод утилиты url_info.sh. Эта утилита, которая используется в check_rkn_report.sh, теперь ее вывод более компактный и содержит только нужную информацию
- Исправлена логика работы с https ресурсами в разборе единого реестра (незначительные ошибки)
- Исправлено сохранение реестра и запроса/подписи при обновлении Carbon Reductor (в 07:45 больше не приходит письмо о проблемах об актуальности списков)
При обновлении редуктор терял старый реестр и диагностикой отправлялось ошибочное уведомление администратору по электронной почте. - IP адреса ресурсов, исключённых из реестра не удалялись из списка фильтруемых
Баг просуществовал около недели - Исправлены ошибочные срабатывания диагностики на потери пакетов
на сетевых картах - Добавлен скрипт проверяющий наличие шторма прерываний ( irqstorm_check ) добавлен его вызов в nic_tunung_help
- Улучшена обработка некоторых не совсем корректно описанных URL из реестра
- Исключён излишний дебаг скрипта ip_update, из-за которого логи ротировались слишком часто, что приводило к довольно коротким отчётам в вебке (за 1-2 дня).
Релиз Carbon Reductor 5.7.1
Исправления
Во-первых — много исправлений мелких ошибок, возникших после рефакторинга и проявляющихся при первом старте. Первый рестарт — это практически первое впечатление от продукта. Сейчас всё круто.
Ограничение поддержки встроенного в Carbon Billing Softrouter 4 Carbon Reductor
Довольно долго мы наблюдаем не очень хорошую ситуацию с серверами Carbon Billing Softrouter 4 с используемым встроенным Carbon Reductor и сообщаем, что в скором времени мы будем вынуждены прекратить поддержку этой ветки продукта. Собственно эта статья о причинах почему мы это делаем и о том, что делать тем, кто сейчас пользуется Carbon Reductor на этих маршрутизаторах.
Скажем заранее: пользующихся версией Carbon Reductor для CentOS 6 можно поздравить с тем, что их эти проблемы не беспокоят, а уже перешедшим на неё мы очень и очень благодарны.
Проблемы
Первая проблема в том, что это разные продукты с несколько разными задачами, которые при этом сильно зависят друг от друга и одновременно друг другу мешают. Иными словами, задача Carbon Reductor — фильтровать трафик, никак не влияя на качество предоставляемой абоненту связи. Само собой, находясь на сервере, через который абонент идёт в интернет такое невозможно, задержки растут. В случае, если сервер Carbon Reductor обрабатывает зеркало трафика это неважно — оригинальный трафик идёт точно так же как он шёл, если бы Carbon Reductor не было, нагрузка мозгов свитчей от зеркала трафика возрастает незначительно.
Второй проблема является скорее следствием первой. Поскольку проекты сильно зависят друг от друга — нельзя обновлять их по отдельности. А так уж сложилось, что большая часть пользователей маршрутизаторов обновлять их не очень любит, а регулярно и автоматически (2-3 раза в неделю) тем более, ибо это простои в доступе в сеть, а в случае с Billing Softrouter 4, помимо части отвечающей за маршрутизацию обновляется и биллинг. Мы уверены, все системные администраторы считают, что не стоит лишний раз трогать то, что замечательно работает и разделяем это мнение. Однако Carbon Reductor — довольно динамичный проект, новые версии выходят практически каждый день (обычно даже несколько), поскольку практически каждый день меняется наш неидеальный окружающий мир и мы стремимся не отставать от него. Для корректной работы ему необходимо обновляться хотя бы два раза в неделю.
Третья проблема больше внутренняя — сложность в использовании новых технологий в столь стабилизированной платформе. То, что делается в версии для CentOS 6 за час, практически одной строчкой в версии для Carbon Billing Softrouter 4 и Carbon AS 4 иногда приходится делать очень нетривиальным способом. Более того, эти версии довольно отличаются между собой, поэтому Carbon Reductor встроенный в Carbon Billing Softrouter 4 довольно сильно отстаёт от CentOS 6.
Четвёртая причина — в ядре Linux, используемом в Carbon Billing Softrouter 4 имеется небольшая, но неприятная проблема, возникающая очень редко (может не возникать вообще, может возникать раз в полгода), связанная с зацикливанием пакетов при очень активном использовании цели REJECT в iptables, приводящем к зависанию серверов. В последнее время такие случаи участились из-за проведения проверок роскомнадзора (в это время происходит довольно большое число REJECT’ов при срабатывании блокировок). Нам бы не хотелось, чтобы это беспокоило наших дорогих клиентов и их абонентов. До того как появился Carbon Reductor нам удалось сократить частоту появления этой проблемы до двух раз в год на всех клиентов, так что после переезда она вас вряд ли будет беспокоить. В версии ядра, используемой в CentOS этой проблемы уже нет.
Пятая причина — за последний год практически все уже самостоятельно переехали на CentOS 6 ради новых фишек, версию для Carbon Billing Softrouter 4 сейчас используют всего 18 клиентов, сопровождать её дальше становится уже просто не то чтобы невыгодно, скорее неразумно.
Что будет дальше?
Главное то, что мы хотим чтобы у всех наших клиентов был положительный опыт работы с продуктом и отсутствие проблем с роскомнадзором, но дать его в рамках версии для Carbon Billing Softrouter 4 мы далее не можем. Это хорошие и проверенные временем маршрутизаторы, но для фильтрации стоит использовать отдельное решение. Мы уже выпустили версии в которых можно легко (буквально две опции, галочка и IP адрес) настроить зеркалирование трафика с маршрутизатора на отдельный сервер Carbon Reductor и таким образом переехать на него буквально за пару часов (разве что может потребоваться добавить ещё одну сетевую карту под зеркало, чтобы не нагружать сетёвку для абонентов).
Никаких заморочек с лицензиями и так далее мы устраивать не будем, вам не нужно будет даже ничего переоформлять (главное отписаться с техническую поддержку, чтобы мы помогли с переездом на новый сервер и затем с обоих сторон подтвердили что новый сервер работает правильно). Пользователям SLA сопровождение и аутсорсинг мы бесплатно поможем настроить аппаратное обеспечение и подтюнить сетевой стэк нового сервера для максимальной производительности захвата трафика и фильтрации.
План прекращения поддержки
Само собой мы предоставим достаточно времени чтобы переехать и прекратим поддержку не завтра и не через месяц. Блокировать сервера и саботировать их работу мы само собой не будем, нам это ни к чему. Всё работает так же как и сейчас.
- 27 мая 2015 — первое оповещение об этом и прекращение новых продаж лицензий на Carbon Reductor, встроенный в Carbon Billing Softrouter 4. Начало помощи с переездом. До 1 июня 2015 мы постараемся дополнительно уведомить об этом клиентов с встроенным Carbon Reductor персонально.
- 1 августа 2015 — последний полный бэкпорт с версии для CentOS. Без этого вносить мелкие исправления в оставшиеся 4 месяца будет очень сложно из-за большой разницы между ветками. После этого критические исправления в проект вносятся только по заявкам в хелпдеске, с рекомендацией скорейшего переезда на CentOS. На самом деле мы очень надеемся, что таких ситуаций вообще не будет и все отнесутся с пониманием и ещё к началу июля дружно закончат с переездом.
- 1 октября 2015 — после этого какие-либо, даже критические исправления в проект не вносятся даже при наличии жалоб, он остаётся в состоянии «как есть», на любые жалобы ответом будет «нужно переехать на отдельный сервер с Carbon Reductor установленным на CentOS 6″.
Насчёт отдельного сервера — для 100-2000 абонентов хватит практически любого 64битного железа не более чем пятилетней давности, в которое воткнуты две нормальные внешние сетёвки от Intel (для доступа в сеть ладно, так и быть realtek хватит), цена выйдет приблизительно в 25-30 тысяч рублей. В скором времени мы подготовим более качественные рекомендации по железу с конкретными примерами.
И самое главное — мы обязательно всем поможем с переездом!
