Продукты

Доброго времени суток!

Продолжаем оптимизировать работу Carbon Reductor под новые реалии контроля фильтрации трафика со стороны РКН. Повышена стабильность выгрузки списков, а фильтрация стала еще лучше.

Самое важное

SNI-фильтрация стала значительно надёжнее в большинстве установок, связано с нюансами трафика в зеркале. Возможен незначительный рост (2-10%) нагрузки на сервер.

Исправлена ошибка с неснимающимся режимом обслуживания на старых выпусках CentOS (6.6 и младше).

Улучшена производительность резолвера в работе со списками.

Повышена надёжность обновления Carbon Reductor

Улучшена стабильность системы обновления. Добавлена дополнительная проверка в момент запуска обновления на случай если скачались некорректные данные. Ранее в случае ответа с ошибкой всегда запускалось скачивание и при обновлении это могло привести к неработоспособности редуктора. Также обновление самого Carbon Reductor теперь нельзя запустить дважды (спасает при запуске ручного обновления во время автоматического обновления).

Работа со списками

Стали более отказоустойчивыми выгрузка реестра и обновление сигнатур. Обновление списков и загрузка URL/доменов/IP в ядро тоже подверглась улучшениям в плане надёжности и понятности. Логируется статистика модуля до загрузки URL и после.

Другое

• Унифицировано логирование во многих подсистемах: файрвол, обновление сигнатур, режим обслуживания, загрузка URL. Позволит быстрее находить причину сбоев в работе.
• Мастер настройки зеркала трафика и часть других скриптов теперь поддерживают устройства, именуемые не «eth».
• Унифицирована система тестирования. Наведён порядок в тестовой инфраструктуре, не касается конечных пользователей напрямую, но это делает Carbon Reductor более защищённым от ошибок разработчиков.
• Улучшена работа Carbon Reductor в режиме только редиректора для неавторизованных/заблокированных/неплатящих абонентов без каких-либо списков вообще. Также для неавторизованных пользователей не полностью фильтровался HTTPS-трафик — исправлено.
• В веб-интерфейсе в разделе «Информация» теперь выводится информация о файле запроса и его подписи при отсутствии сертификата.
• Mikrotik периодически отдаёт пустой ответ при запросе списка IP адресов, не отдавая никакого кода возврата. Теперь это учитывается в примере хука для интеграции с маршрутизатором.
• Утилита для поиска по кэшу резолва запрещенных доменов теперь умеет искать как домены по IP, так и IP по домену — используется для ресурсов, которые часто меняют IP-адрес.
• Обновлён плагин для collectd (`/usr/local/Reductor/bin/collectd_plugin`), теперь он соответствует новому формату собираемой по модулям ядра статистики.
• Исправлено несколько опечаток в диагностике и веб-интерфейсе.

Спасибо, что пользуетесь Carbon Reductor!

Добрый день!

Изменения в связи с обновлением АС «Ревизор»

Добавлен режим обслуживания

В случае, если новая версия Carbon Reductor содержит изменения модулей фильтрации, на время процесса обновления, 10-20 секунд, включается режим обслуживания. Правила файрвола не очищаются полностью, вместо этого добавляется REJECT для всех видов трафика. Эти правила применяются только для АС «Ревизор», если указан его IP‑адрес/подсеть, иначе — для всех абонентов. Это сделано с целью исключить пропуски фильтрации в процессе обновления Carbon Reductor. Такие обновления бывают раз в 2-3 месяца.

А также:

• Теперь не указанный IP-адрес АС «Ревизор» считается ошибкой.
• Добавлена регистронезависимая фильтрация DNS для всех абонентов, если не указан IP‑адрес/подсеть АС «Ревизор». Может повышать нагрузку на сервер.

Повышение надёжности фильтрации

• Теперь в файлах модулей фильтрации выводится статистика по обеим базам данных — как buffer, так и readonly. Ранее счётчики показывались не совсем верно — в какой-то момент от buffer, в какой-то от readonly, что могло привести к ошибочному выводу о том, что база, по которой происходит поиск при фильтрации, обнуляется при обновлении списков или рестарте.
• Загрузка URL, доменов и IP в ядро теоретически могла быть запущена в процессе обработки списков и использовать не до конца обработанные списки — исправлено.

Исправления в Carbon Reductor 8

• В момент применения собственных списков в веб-интерфейсе выдавалась 404/500 ошибка.
• L2-зеркало трафика, настроенное с помощью мастера не работало.
• Использование страницы-заглушки Carbonsoft теперь считается ошибкой, т.к. ответ от сервера Carbonsoft не является гарантированным.
• Мелкие проблемы с запуском при первой установке.
• Ошибка в веб-интерфейсе, в некоторых случаях возникала надпись «Файл не найден».
• Ошибка генерации и подписи запроса для получения списка запрещённых сайтов, в результате которой списки не выгружались.

Прочее

• Исправлено — Satellite не удалял пустые временные файлы на каждый домен при проверке DNS, что приводило к заполнению inodes. Проверить текущую заполненность можно командой: df -hi /tmp/.
• Теперь в отчётах Satellite указывается его IP-адрес. Полезно при использовании нескольких серверов Satellite.
• Плагин collectd сломался при обновлении модулей. Теперь он поставляется в комплекте с Carbon Reductor, чтобы обеспечить его автоматическое обновление. Инструкция на github по работе с ним в скором времени будет обновлена и продублирована в документацию Carbon Reductor.
• Добавлен режим для Satellite, обеспечивающий отсутствие расхождения содержимого списков на Reductor и Satellite на время проверки фильтрации (используется только в целях агрессивного тестирования разработчиками).

Спасибо, что пользуетесь Carbon Reductor!

Доброго времени суток!

Роскомнадзор вновь подкидывает работы и заставляет некоторых пользователей понервничать.

У нас есть страница-заглушки: http://denypage.ru. Давненько, когда модуль DNS-фильтрации стал необходим для прохождения проверок ревизора без пропусков, мы приняли довольно тяжелое решение о том, чтобы при обновлении включить этот модуль.

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

Взглянули на нагрузку, которую она создаёт и в принципе ничего особо страшного не было. Доросла она где-то до 100-400 тысяч запросов в час и это никого не беспокоило.

После обновления АС «Ревизор», 21 декабря — нагрузка на страницу выросла до 7 000 000 запросов в час, и это только те, которые достучались до контейнера с nginx, обслуживающим эту страницу. Многие запросы стали заканчиваться ошибками HTTP/502 Gateway Timeout, которые фиксируются ревизором. К штрафу это, скорее всего, не приведёт, т.к. ответа от запрещенного ресурса не было, но из РЧЦ к Вам придут с вопросом: «а почему у Вас нет страницы-заглушки?».

Чтобы фильтрация работала как положено нужно настроить собственную страницу заглушку.

Настройка заглушки, варианты:

На отдельном сервере

Чтобы АС «Ревизор» её успешно распознавал, следуйте инструкции (имеющиеся веб-сервера использовать не рекомендуется, потому что инструкция требует выделить отдельный сервер, занимающийся ТОЛЬКО страницей-заглушкой, в противном случае отправленные с помощью DNS-спуфинга редиректы не будут обработаны этим сервером):

https://github.com/carbonsoft/reductor_blockpages

После настройки страницы надо указать в двух местах адрес, доступный всем абонентам и АС «Ревизор»:

1. Menu -> Настройка алгоритма фильтрации -> URL страницы-заглушки.
2. Menu -> Настройка алгоритма фильтрации -> IP для DNS-ответов.

На сервере с Carbon Reductor

Не рекомендуется при большой нагрузке. (1000+ абонентов/несколько ревизоров).

Включить можно в «menu -> Настройка алгоритма фильтрации -> Заглушка на этом сервере».

После настройки страницы надо указать в двух местах адрес, доступный всем абонентам и АС Ревизор:

1. Menu -> Настройка алгоритма фильтрации -> URL страницы-заглушки.
2. Menu -> Настройка алгоритма фильтрации -> IP для DNS-ответов.

Почему нельзя использовать нашу страницу заглушку в продакшене

• Она изначально предназначена исключительно для целей тестирования работоспособности продукта во время демо-периода, а также в являлась временным решением многомесячной давности.
• Канал до неё имеет ограничение в 100 Мбит/с, ресурсы процессора тоже имеют свои ограничения. Мы не можем гарантировать её 100% доступность.
• Также мы не можем гарантировать то, что ревизор не опознает недоступность нашей страницы-заглушки как доступность блокируемого сайта.

В конце концов, отправлять трафик абонентов и ревизора на нашу заглушку — лишняя нагрузка аплинков, да и интернет штука далекая от 100% надёжности. В общем, единственный способ правильно решить проблему — разворачивать заглушку на отдельном сервере.

Если Вы пропустили статью о том, что обязательно нужно настроить, чтобы не иметь пропусков — пройдитесь по ней.

Доброго времени суток!

В этом месяце у нас сразу два релиза. Теперь Carbon Reductor доступен на платформе Carbon, проверенной годами эксплуатации Carbon Billing 5. Carbon Reductor 8 успешно внедрён у 5 провайдеров, в него полностью портированы все исправления и доработки из версии, поставляемой в RPM для CentOS (Carbon Reductor 7). Но обо всём по порядку.

Carbon Reductor 7.4.9 300

Файрвол

Снижена нагрузка на модуль SNI-фильтрации

Теперь туда попадают только пакеты длиннее 60 байт. SNI всё равно не может оказаться в SYN/RST/FIN и других коротких пакетах без данных, но полагаться только на TCP-флаги было бы неправильно.

Изменения и исправления в блокировке HTTPS по IP

При отключении блокировки HTTPS по IP не работала блокировка адресов вида https://1.2.3.4.ru/something. Опция «Блокировать HTTPS по IP» немного изменила своё поведение:

• включено: Блокировать HTTPS по IP для всех записей в едином реестре, где встречаются HTTPS-ссылки;
• выключено: Блокировать HTTPS по IP только в случаях, если иначе заблокировать ресурс невозможно.

«Под капотом» это выглядит как разделение списка IP в файрволе на 2 ipset:

• `ip_https` — ресурсы, которые можно заблокировать только по IP, используется всегда, независимо от опций;
• `ip_https_plus` — дополнительные IP адреса для блокировки на портах HTTPS. Включается опцией «Блокировать HTTPS по IP».

Опция «Использовать nslookup» использует резолвер для расширения списка IP для ipset `ip_https_plus`.

Исправлено: не блокировались нестандартные порты HTTPS при включении опции «оптимизация подсистемы роутинга»

На самом деле, пока всего 1 порт. Однако, несмотря на то, что это исправлено — рекомендуем всё равно эту опцию выключить, она является сильно устаревшей и даёт мало пользы в большинстве случаев.

Затем не забудьте проверить изменение нагрузки на сервер (до и после выключения и рестарта) с помощью утилиты `/usr/local/Reductor/bin/net_rx_top.sh`, оно не должно превышать 25000 прерываний на ядро. В противном случае необходимо решать проблему с производительностью, лучше горизонтальным масштабированием.

Опции «Использовать SNI» и «Использовать NOTRACK» теперь включаются при обновлении автоматически

Единоразово, затем их можно отключить. Благодаря тому, что свой IP адрес мы удаляем в цепочке `raw -> PREROUTING -> mirror_info` опция NOTRACK теперь полностью безопасна. SNI-модуль успешно прошёл экспериментальную фазу и хорошо себя зарекомендовал более чем на 80 серверах, перед тем как быть включённым по умолчанию.

Прочие исправления

• редуктор не стартовал при основном маршруте через девайс, а не IP шлюза;
• использование дополнительных правил фильтрации https приводило к невозможности старта Reductor;
• DNS-спуфинг мог зацикливать HSTS-прокси, если его трафик попадал в зеркало. Сейчас трафик с его IP игнорируется.

Утилиты для отладки и обработка списков

Работа обработки списков URL ускорена в 7 раз

Однажды, в выходные была предпринята попытка всё переписать на Go, которая закончилась профилированием, изменением 8 строчек в одной функции.

Результаты замера скорости обработки списков. Окружение: CentOS 6, KVM, 2 виртуальных ядра, 1Gb RAM, виртуальный диск (qcow2, writeback), список `rkn.url_http`, на момент замера 39000 URL.

• Старая версия, python 2.6: 0m21.163s
• Старая версия, pypy2.7: 0m5.310s
• Новая версия, python2.6: 0m3.312s
• Новая версия, pypy2.7: 0m3.560s

Один из наиболее важных вариантов экранирования пропускался

Ошибка, связанная с всего-лишь одной запятой, имелась с ноября 2015 года, но никем не была замечена. Имеется только один подтверждённый факт пропуска одного URL. В итоге число предобработанных для загрузки в ядро на выходе повысилось с ≈43000 до ≈52000 (для алгоритма match-модуля это на самом деле крайне незначительно влияет на производительность).

Небольшое, но важное исправление в связке с маршрутизаторами по BGP

Скрипт для блокировки/разблокировки ресурсов по IP на маршрутизаторах некоторое время не мог найти файл `ip_block.load`. Это исправлено, но возможно имело последствия, так что всем использующим интеграцию с маршрутизаторами средствами BGP рекомендуется обновить хук и проверить, что успешно анонсируются все IP адреса. В противном случае может помочь инструкция.

Прочее

Добавлено:

• утилиты для отладки: `support_info.sh` теперь показывает статистику по дисковому пространству;
• утилиты для отладки: утилита показывающая информацию по доступным обновлениям. Запуск — `/usr/local/Reductor/bin/check_update_human.sh`;
• выгрузка списков: возможность выполнять клиентские хуки до начала выгрузки. В `userinfo/hooks/rkn_download.sh` достаточно определить функцию `client_pre_hook()`.

Исправлено:

• утилиты для отладки: скрипт `url_info.sh` пытался искать данные в старых списках;
• мастер настройки сети: L3 vlan схема не работала из коробки, не хватало опции `VLAN=yes` в шаблоне конфига интерфейса;
• обработка списков: списки Carbon Soft для временных решений качались в старом формате -> не использовались;
• обработка списков: не выкачивались сигнатуры для URL с несколькими пробелами;
• обработка списков: не работала DNS-фильтрация при пустых строках в списках провайдеров. Помимо этого обработка стала активнее и явнее отсекать невалидные данные, например URL с доменами первого уровня при обработке списков URL.

Резолвер

Не удалялись временные файлы

Могло привести к переполнению `/tmp/`, особенно там, где используется реальный `tmpfs`. Благодаря своевременному критическому обновлению проблема успела проявиться только на двух наблюдаемых мониторингом серверах, у одного из которых было отключено критическое обновление, где была устранена вручную.

Прочие исправления логики после переезда на новые списки

Теперь создаётся симлинк `/usr/local/Reductor/lists/https.resolv` для совместимости с `named fakezone generator`

С ним уже найдено и исправлено несколько багов:

• домены для отправки в прокси по DNS могли начать блокироваться по IP из-за попадения в https.resolv;
• запуск старого резолвера в cron.d приводил к занулению https.resolv;
• создание https.resolv происходит даже если резолвер выключен;
• мог быть заблокирован IP адрес страницы-заглушки.

Тесты

«Service reductor restart» всегда возвращал нулевой код возврата, даже если писал об ошибках. Это исправлено, так что у нас появились pairwise тесты параметров фильтрации, позволяющие за полторы минуты достаточно достоверно подтверждать отсутствие проблем в опциях и сочетаниях опций (пусть и только попарных, но это в разы лучше, чем ничего), приводящих к невозможности запуска.

Исправления

• satellite: Carbon Reductor Satellite стал проверять фильтрацию в 2.5 раза быстрее благодаря более оптимальному алгоритму разделения ресурсов для проверки между потоками;
• satellite: не разбирался реестр из-за неполного конфига;
• диагностика/ошибки настройки: не показывались подробности по проблемам: интеграция с маршрутизаторами, уведомления админа редиректом;
• мастер настройки: не запускался выбор метода обновления списков РКН (web, xml, pem);
• интеграция с биллингом: не работала при ненастроенной DNS-фильтрации.

Reductor 8.0.0 1395

Отличия от 7 версии

Форма поставки

Основным различием является форма поставки приложения. Теперь Carbon Reductor поделен на отдельные приложения: reductor, blockpage и https_proxy (последние два могут быть отключены), а на подходе и satellite. Каждое приложение поставляется в виде изолированного chroot-окружения, где есть всё, что ему необходимо для работы. Помимо них есть ещё два обязательных контейнера:

• base — даже не контейнер, а просто папка с утилитами для управления остальными контейнерами и парой конфигов в корне;
• auth — система авторизации в веб-интерфейс управления сервером.

Все обновления бинарные

Подтягиваются только изменения, скачивание обновления отделено от применения. Незначительным минусом является, пожалуй, размер приложений, но он заметен только при первой установке через медленный канал. В чём-то это схоже с Red Hat Atomic Host / Docker, только без заморочек с «только один запущенный процесс на контейнер» и нет ограничений на работу с ядром хост-системы. Есть и минус — больше нет возможности отката на предыдущую версию, но мы что-нибудь придумаем.

Установка происходит с универсального ISO-образа

Образ автоматически сделает надёжную разбивку дисков, используемую платформой Carbon, соберёт при необходимости софтрейд. Подробнее о процессе установки можно узнать в соответствующей статье в документации.

Диагностика происходит раз в 5 минут

А не так как ранее — раз в час. Запускается отдельно для всех приложений. Веб‑интерфейс редуктора в диагностике показывает все найденные предыдущими запусками ошибками с подробностями, но не запускает саму диагностику.

Изменения в бизнес-процессах

Теперь новые внедрения происходят только для Carbon Reductor 8, а все изменения в первую очередь вносятся в неё, затем при необходимости бэкпортируются в Carbon Reductor 7.

Точного плана по прекращению поддержки Carbon Reductor 7 ещё нет, но мы обязательно сообщим о нём за 2-3 месяца и поможем переехать. Переезжать, пока, стоит только согласовав всё с технической поддержкой, лучше предварительно обкатав восьмую версию на тестовом сервере и убедившись в том, что с ней нет никаких проблем. Проблемы возникшие в результате самостоятельного обновления на 8 версию на продакшне, пока что, не являются критическими и не подлежат приоритетному решению.

Автоматический переезд с 7 версии на 8 сложен технически, в основном из-за недетерминированности хуков и изменений в именовании цепочек файрвола. Тем, кто использует Carbon Reductor без дополнительных наработок, будет значительно проще всё это сделать. Многие типовые хуки уже были включены в виде опций в дистрибутиве, некоторые стали частично бессмысленными после изменения схемы файрвола (ACCEPT в mangle для zabbix например).

Изменения за последний месяц в 8 версии

• исправлены многочисленные мелкие проблемы с путанницей в местоположении файлов (меняющиеся данные находятся на отдельном разделе);
• адаптирована к платформе Carbon система диагностики, теперь каждая проверка находится в отдельном файле и может быть запущена без запуска остальных;
• загрузка списков в ядро стала отказоустойчивее к проблемам отдельных модулей — если один из модулей по какой-либо причине не работает, хотя и должен:
  1. Будет выведено соответствующее сообщение об ошибке.
  2. Скрипт продолжит работу.
  3. Зальёт списки в остальные модули, если это удастся.
  4. Завершится с ошибкой.

Спасибо, что пользуетесь Carbon Reductor!

Мир вокруг меняется, бизнес-правила тоже. Законопроект на 21 ноября 2016 ещё находится на рассмотрении, но скоро будет принят. Теперь нужно внимательней следить за фильтрацией, иначе любой пропущенный пакет от «Ревизора» может обернуться штрафом. Всё, что мы можем делать со своей стороны мы делаем, но многие вещи может сделать только сетевой/системный администратор провайдера.

Пойдём по порядку

Настроить Satellite

Ревизор, конечно, всё проверяет, но когда проверка чревата штрафом спокойно отладить блокировку становится невозможно. Мы сделали аналог АС «Ревизор», проверяющий HTTP, HTTPS и DNS фильтрацию и не «стучащий» никуда, кроме почты администратора.

Обновить настройки зеркала трафика

Зеркалировать tcp/80, tcp/443 и udp/53 недостаточно. Нужно отправлять либо весь исходящий трафик абонентов, либо автоматически, или хотя бы периодически следить за тем, что нужно Carbon Reductor для анализа:

• udp/53 — пока единственный порт на котором анализируется DNS трафик;
• /usr/local/Reductor/lists/load/port_http.load — файл-список tcp dst портов;
• /usr/local/Reductor/lists/load/port_https.load — файл-список tcp dst портов;
• /usr/local/Reductor/lists/load/ip_port.load — файл-список связок из ip + dst портов (tcp и udp);
• /usr/local/Reductor/lists/load/ip_block.load — файл-список IP которые надо блокировать целиком, независимо от IP.

Настроить свою страницу-заглушку

На отдельном сервере с IP-адресом, доступным абонентам. Это нужно для корректной работы DNS-спуфинга для блокировки по домену. Есть готовое решение.

Можно настроить это на самом Carbon Reductor, но по причине в конце статьи — лучше на отдельном веб-сервере.

Настроить SNI-фильтрацию

Появился довольно неплохой модуль, фильтрующий обращения к HTTPS ресурсам по домену, указанному в поле SNI в пакете Client Hello.

Menu -> «Настройка алгоритма фильтрации» -> «Фильтровать HTTPS по SNI»

Настроить DNS-фильтрацию

В реестре появилось много ресурсов, которые требуется блокировать по домену. А это означает не только по HTTP/HTTPS, а любое обращение к этому домену. В Carbon Reductor появился модуль DNS-спуфинга, вам нужно:

1. Включить его.
2. Указать IP-адрес настроенной выше страницы-заглушки.
3. Указать IP-адрес ревизора (облегчит отладку пропусков блокировок, происходящую постфактум, если это произойдёт).

Интеграция с DNS-серверами

Когда DNS-запросы от Ревизора попадают в DNS-сервера провайдера, они:

1. Не факт, что попадут в зеркало трафика Carbon Reductor.
2. А если и попадут, то не факт, что DNS-сервер примет их из-за DNSSEC-валидации.

Поэтому хорошим решением будет подружить DNS-сервера с Carbon Reductor, научив его отвечать на блокируемые домены IP адресом страницы-заглушки с помощью простого набора скриптов:

• unbound;
• bind/named;
• другие — либо брать bind/named и дорабатывать под свой dns-сервер по аналогии, либо отключать DNSSEC-валидацию.

Интеграция с маршрутизатором

Некоторые ресурсы необходимо блокировать полностью по IP по всем протоколам. Находясь в зеркале это сделать невозможно (хотя мы и присылаем соответствующие tcp/icmp ответы на такие обращения), поэтому блокировать их лучше на маршрутизаторе. Каким образом — на ваше усмотрение:

1. Использование BGP/OSPF Remote Triggered Blackhole.
2. Настроить отправку команд на оборудование для добавления/удаления/получения списка заблокированных IP в хуке events.sh.

Скорее всего почистить собственные белые списки

Быть добрым к клиентам и разрешить доступ к популярным заблокированным ресурсам типа «рутрэкера» или «порнхаба» было здорово, но теперь это может обойтись довольно дорого.

Настроить дополнительные параметры мониторинга

Первым делом стоит настроить хоть какой-то мониторинг за Carbon Reductor. Там внутри Linux, так что следить хотя бы за его состоянием будет уже хорошо. Но помимо прочего, стоит следить и за состоянием самого Carbon Reductor. Есть готовые плагины для collectd, на их основе можно соорудить аналоги для используемых вами систем мониторинга.

Вообще, мы подумываем сделать полноценный облачный мониторинг, куда сливать кучу подробностей о состоянии серверов и самостоятельно заниматься отслеживанием аномалий и т.д., но здесь есть много «privacy issues», по крайней мере, без согласия представителей провайдера мы это точно делать не можем.

Добиться идеального latency

В случае с анализом зеркала трафика важно, чтобы срабатывание происходило гарантированно быстро. Подробнее почитать про это можно по ссылке.

Кратко:

• купить хорошие сетевые карты и обязательно настроить их;
• отказаться от виртуальных машин и перейти на железо;
• избавиться даже от единичных потерь на стороне зеркалирующего оборудования;
• озаботиться тем, чтобы Carbon Reductor не занимался ничем кроме фильтрации, в том числе и веб-сервером;
• отправить критически важных абонентов в разрыв через Carbon Reductor чтобы не беспокоиться о потерях на свитче;
• заиметь резервный сервер Carbon Reductor (безвозмездно) и настроить схему с их взаимодействием, которая скоро появится;

Что мы планируем сделать со своей стороны в будущем:

Возможность разнести управление и фильтрацию по отдельным машинам

Управление — сервер, отслеживающий и поддерживающий одинаковую конфигурацию на всех фильтрующих серверах.

• конфигурация;
• веб-интерфейс;
• выгрузки;
• обработка списков;
• принятие решения об обновлении себя и серверов фильтрации;
• часть диагностики;
• активация;
• резолв;
• взаимодействие с оборудованием провайдера;

Фильтрация — сервер который занимается только фильтрацией трафика, не имеющий никаких периодических задач.

• фильтрация HTTP запросов;
• фильтрация HTTPS по Client Hello и IP;
• фильтрация DNS запросов без DNSSEC;
• фильтрация других протоколов по IP / IP+port;
• загрузка URL/доменов/IP при необходимости;
• часть самодиагностики;

В итоге планируется получить схему, в которой возможно полностью избежать:

1. Downtime при обновлениях, штатном обслуживании и перезагрузках, даже если необходимо заменить модули в памяти.
2. Нагрузки на сервере фильтрации, способной привести к задержке ответа -> пропуску фильтрации.

Это потребует выноса Carbon Reductor для управления на отдельную машину, но к ней не будет требований по скорости работы! А это означает возможность его работы в виртуальных машинах, даже внутри легковесных Linux-контейнеров. И тут появляется возможность держать прямо на этом же сервере:

• Carbon Reductor Manager;
• Carbon Reductor Satellite;
• Carbon Reductor Blockpage;

Задача их одновременной работы довольно сложная, но в этом нам может помочь описанное в следующем пункте.

Переход на Carbon Platform 5

Готовое и проверенное годами работы Carbon Billing 5 решение для работы нескольких бизнес-приложений. Бонусы:

• привычно для разработки любым разработчиком Carbon Soft — проще привлечь для помощи коллег из других проектов;
• привычно для обслуживания любым инженером техподдержки Carbon Soft — ответы в хелпдеске будут быстрее;
• с платформой в бонус идут некоторые решения, повышающие общую надёжность системы:
  • watchdog;
  • дефолтные настройки Linux;
  • правильная разбивка дисков;
  • система обновления, позволяющая получать только полностью проверенные обновления, но оставляющая возможность совместно обкатывать новые возможности.
• веб-интерфейс, который даёт авторизацию и возможность конфигурировать приложения в браузере. Более того, его использование снимает около 35% подзадач из эпичной задачи, которую мы пока отложили — веб-интерфейс 2.0.

Изменение схемы файрвола

Использование iptables для фильтрации трафика даёт много удобств (не надо писать свой ip/tcp-стэк, логика с проходом пакетов по цепочкам тоже довольно упрощает жизнь), но и много неудобств, одно из них — match-модули не могут возвращать что-то кроме boolean значений (true/false).

Это не подходит для классификации. По уму надо давно взять PF_RING / NETMAP / что-то ещё и переписать всё на работу в userspace, но по сути это разработка нового продукта и требует достаточно времени свободного от срочных задач. Увы, Роскомнадзор и Государственная Дума не спят и постоянно эти задачи создают.

Но недавно мы продумали одну хорошую идею — как дать возможность классификации нашим http / https / dns -модулям при использовании многих списков практически без потери производительности:

1. Match-модули будут заниматься только проверкой факта, что пакет можно разобрать и проанализировать, в противном случае пакет отбрасывается.
2. Поиск по базам доменов и URL будет происходить в TARGET модуле (который не будет получать «мусорных» пакетов), оставляющем метку с ID базы, в котором данный домен/URL найден.
3. Далее, в зависимости от этой метки будет срабатывать отдельное правило с TARGET’ом-соответствующим редиректом. Сравнение меток — дело копеечное, так что правил можно будет вешать сколько душе угодно.

Оптимизация в работе модулей фильтрации

Если остались вопросы

Создайте заявку на тему в портале технической поддержке Helpdesk, мы поможем Вам с настройкой.