... {toc}
h2. Как включить модуль
В меню "Опции Carbon Reductor DPI X" выбрать опцию "Включить интеграцию с DNS".
Сама по себе опция отвечает только за то, что модуль будет включен. Нужно обязательно выбрать одну или несколько задач для него.
h2. Что нужно сделать на DNS-сервере
Модуль только подкладывает подключаемые файлы в нужные места. В некоторых дистрибутивах в основном конфигурационном файле не настроено их подключение. Мы не хотим повредить возможные ручные настройки, поэтому это нужно сделать вручную.
*Unbound 1.4.20 (CentOS 6)*
Всё обычно работает "из коробки". Более подробно можно прочитать в нашей статье - [http://docs.carbonsoft.ru/113999917].
*Unbound 1.6.0 (Debian 9)*
* Создать директорию /etc/unbound/local.d/
* В файле /etc/unbound/unbound.conf.d/unbound.conf в конце секции "server:" указать include: /etc/unbound/local.d/*.conf
h2. Что нужно сделать на Carbon Reductor
h3. Авторизация по SSH-ключам
С каждым DNS-сервером с которым настраивается интеграция должна быть настроена авторизация по SSH ключам.
Для начала нужно подключиться по SSH к серверу с Carbon Reductor DPI X.
Все дальнейшие команды нужно выполнять внутри контейнера Carbon Reductor DPI X, перейти в него можно командой.
{code}
chroot /app/reductor/
{code}
Создаётся пара SSH-ключей:
{code}
ssh-keygen
{code}
Команда будет задавать вопросы, нам подходят значения по умолчанию, просто нажимаем Enter несколько раз.
Ключи отправляются на DNS-сервера. К примеру IP адрес DNS-сервера - 10.15.0.24, тогда команда для отправки выглядит так:
{code}
ssh-copy-id root@10.15.0.24
{code}
Обязательно проверьте, что после этого подключение по SSH успешно проходит и не запрашивает ввод пароля или yes/no.
h4. Ограничения
|
...
Помимо опции "Включить интеграцию с DNS" необходимо указать ещё две опции:
h3. IP-адреса DNS-серверов
Если вы используете несколько одинаковых DNS-серверов, Carbon Reductor DPI X позволяет отправлять сгенерированные файлы зон на каждый из них.
Для этого их адреса нужно перечислить через пробел в этой опции.
h3. Тип DNS-сервера
Выберите тип DNS-сервера, который вы используете. На текущий момент варианта два:
* Unbound
* Bind / Named
Bind / Named хуже чем Unbound справляется с большим набором зон: потребляет больше оперативной памяти, перечитывание конфигурации занимает больше времени. Если вы планируете использовать Bind / Named для блокировки ресурсов, мы рекомендуем перейти на Unbound. Если использовать его только для разблокировки частично заблокированных ресурсов - проблем быть не должно.
*Важно:* один сервер Carbon Reductor DPI X может работать только с одним типом DNS-серверов, т.е. тип DNS-сервера - глобальная опция. Если в вашей сети используются и Bind / Named и Unbound одновременно, рекомендуемое решение - использовать два сервера с Carbon Reductor DPI X. Лицензию на второй сервер Carbon Reductor DPI X можно получить бесплатно в качестве резервного сервера и установить его в виртуальную машину.
h2. Задачи модуля
h3. Блокировка ресурсов по домену
Возможно вы уже пользовались прототипом модуля, который устанавливался непосредственно на DNS-сервер и обращался к Carbon Reductor за списками.
Сейчас схема изменилась - Carbon Reductor DPI X локально генерирует конфиги с DNS-зонами для заблокированных сайтов и отправляет их на DNS-сервер.
Если ранее использовался прототип - его необходимо отключить, удалив файл с параметрами запуска из директории /etc/cron.d/ на DNS-сервере.
*Зачем это нужно, если есть модуль DNS-спуфинга?*
# *Иногда трафик не анализируется.* Если пользователь обращается к DNS-серверу в локальной сети, его запросы могут не попадать в зеркало трафика, которое настроено для отправки трафика, уходящего за её пределы. Тем не менее трафик с последующим запросом будет заблокирован либо HTTP, либо SNI модулями, либо по IP.
# Использование только *SNI*\-фильтрации *не перенаправляет на страницу-блокировки*. Анализировать HTTPS-трафик с точностью до домена можно и без DNS, но перенаправление на страницу блокировки - это понятнее для пользователя чем просто разрыв сессии. У него не возникнет лишних вопросов к службе технической поддержки провайдера.
# *Снижение нагрузки* с сервера фильтрации. В случае успешной фильтрации с помощью DNS-сервера запрос пользователя будет направлен к серверу страницы блокировки. Этот трафик не анализируется модулями фильтрации. Особенно актуально это для крупных провайдеров с субпровайдерами - один сервер анализирует трафик от нескольких АС Ревизор, у которых частота запросов к запрещённым сайтам значительно выше, чем у обычных абонентов.
h3. Избежание частичных блокировок популярных ресурсов
Это новая, экспериментальная возможность в Carbon Reductor DPI X и сейчас она активно дорабатывается.
*Схема работы:*
# Модуль читает список частично заблокированных ресурсов. Его формируют администратор сервера и Carbon Soft, при использовании опции "Разблокировать популярные сайты в обход требований Роскомнадзора".
# Домены резолвятся, получаем набор связок "домен" - "список IP"
# Модуль читает список заблокированных целиком IP адресов.
# Заблокированные адреса удаляются из результатов резолва.
# Если ни один IP адрес ресурса не заблокирован - зона не генерируется.
# Если все IP адреса ресурса заблокированы - зона не генерируется.
# В остальных случаях из незаблокированных IP адресов формируется DNS-зона для домена.
# Из зон формируются конфигурационные файлы.
# Конфигурационные файлы отправляются на DNS-сервер.
# При наличии возможности (есть в Unbound) они валидируются. Если валидация не проходит - удаляются.
# Если всё в порядке - вызывается перечитывание конфигурационного файла.
# Абоненты, использующие DNS-сервер провайдера, при обращении к частично заблокированному ресурсу не получают заблокированные IP.
# В итоге они не замечают частичных блокировок.
# Снижается нагрузка на техническую поддержку провайдера
*Пример*
Ресурс example.com имеет 4 IP адреса: 1.2.3.1, 1.2.3.2, 1.2.3.3, 1.2.3.4.
1.2.3.1 - заблокировали, т.к. этот адрес используется также ресурсом block-me.com, попавшим в реестр РКН.
Пользователь Петя обращается к этому ресурсу. Его DNS-сервер присылает ответ:
{code}
;; ANSWER SECTION:
example.com. 299 IN A 1.2.3.1
example.com. 299 IN A 1.2.3.3
example.com. 299 IN A 1.2.3.4
{code}
ОС используемая Петей выбирает 1.2.3.1, запоминает этот адрес, чтобы не обращаться лишний раз к DNS-серверу.
В результате дальнейшие обращения к этому сервису до тех пор, пока адрес не устареет в DNS-кэше ОС Пети будут блокироваться.
В случае если используется модуль интеграции с DNS-сервером для разблокировки частично заблокированных популярных ресурсов, а Петя использует DNS-сервер провайдера произойдёт следующее.
Carbon Reductor отрезолвит example.com, получит тот же ответ что и Петя:
{code}
;; ANSWER SECTION:
example.com. 299 IN A 1.2.3.1
example.com. 299 IN A 1.2.3.3
example.com. 299 IN A 1.2.3.4
{code}
Т.к. 1.2.3.1 заблокирован, модуль создаст для example.com зону, например:
{code}
local-zone: "example.com" redirect
local-data: "example.com A 1.2.3.3"
local-data: "example.com A 1.2.3.4"
{code}
и применит её на DNS-сервере.
Далее, когда Петя обратиться к DNS-серверу чтобы узнать IP адрес example.com он получит ответ:
{code}
;; ANSWER SECTION:
example.com. 299 IN A 1.2.3.3
example.com. 299 IN A 1.2.3.4
{code}
и не заметит проблем с доступом к этому ресурсу.
*Когда этот модуль не поможет*
В случае если ресурс заблокирован полностью - модуль не сможет подобрать для него незаблокированные адреса по причине того, что их просто нет.
h2. Как тестировать
Для разблокировки нужно только установить галочку. Для разблокировки ресурса нужно добавить домены в файл:
{code}
/var/lib/reductor/lists/provider/domain_fakezone_save.load
{code}
В обоих случаях запустите
{code}
/opt/fakezone/bin/main.sh
{code}
При возникновении ошибок - создайте заявку в хелпдеске и приложите полный вывод команды main.sh.
h2. Известные ошибки
h3. Дублирующиеся зоны в Unbound
Если для одного домена создано несколько зон - это приведёт к ошибкам. Это происходит когда для него создаётся зона двумя из трёх возможных способов:
# Для блокировки по домену
# Для избежания частичной блокировки
# Вручную администратором
На текущий момент защиты от этого в модуле нет.
|
