Проверка состояния активации

В нормальном настроенном состоянии Carbon Reductor регистрируется и активируется автоматически.

1. Проверьте то, что у Carbon Reductor имеется доступ в интернет и его никуда не редиректит. Возможна ситуация - сервер добавлен в биллинговую систему как абонент и через некоторое время он уходит в отрицательный баланс и все его запросы редиректятся на страницу-заглушку или просто отбрасываются.
2. Проверьте настройки выгрузок единого реестра
3. Проверьте то, что в системе настроен правильный часовой пояс
4. Проверьте то, что у вас работает DNS (достаточно ping -c 1 ya.ru)

Проверка настроенного bridge

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

Проверка наличия IP адресов на интерфейсах в bridge

По умолчанию скрипты CentOS при добавлении ethernet интерфейсов в bridge игнорируют наличие в их конфигах IP адресов. В таком случае пакеты не попадают в iptables (что в принципе логично). Но поскольку нам они там нужны, carbon reductor при каждом рестарте подменяет скрипт ifup-eth. Для того чтобы пакеты попали в iptables достаточно наличия любого IP адреса на интерфейсе, куда приходит зеркало. Так что обычно для того чтобы это исправить достаточно выполнить команды
Проверка настроенного bridge
Проверка наличия IP адресов на интерфейсах в bridge

service reductor restart
service network restart

в противном случае - скорее всего настройки одного из интерфейсов неправильные и ему нужно назначить IP адрес (лучше из сети 169.255.255.0/24, но с маской 32).

Подгрузка модуля

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

service reductor restart

Если он пишет ошибки при старте, может помочь эта статья.

Проверка proc-параметров

Такое происходит когда кто-то или что-то помимо Carbon Reductor пытается настраивать различные proc-параметры, необходимые ему для работы.

Найти их список можно в скрипте /usr/local/Reductor/bin/start.sh в функции set_proc_values.

Проверка запущенного crond

К сожалению обнаружить эту ошибку можно только запустив диагностику вручную, поскольку диагностика вызывается из crond.

Если повторная диагностика снова её находит, вам нужно разобраться почему не удаётся перезапустить crond.

Наличие сертификата

Проверка наличия файла /usr/local/Reductor/userinfo/provider.pem

Наличие закрытого ключа в provider.pem

Проверка того, что в /usr/local/Reductor/userinfo/provider.pem имеется секция PRIVATE KEY, которая собственно используется для подписи.

Если файл есть, а секции нет - скорее всего файл был экспортирован неправильно.

Внезапно случиться (если до этого всё работало) может разве что при проблемах с файловой системой или жёстким диском.

Время до конца работы ключа provider.pem

К сожалению, ключи выдаются с ограниченным сроком действия (обычно на год) и по истечении срока действия приходится покупать новый в Удостоверяющем центре.

За две недели до окончания срока действия ключа Carbon Reductor предупреждает о возникшей проблеме.

Обычно этого срока достаточно, чтобы заказать новый.

Проверка работоспособности DNS-сервера

Многие функции Carbon Reductor сильно зависят от работы DNS, используемого на нём.

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

Если с качеством канала, предоставляемого серверу Carbon Reductor ничего поделать нельзя, можно попробовать использовать nscd и ещё пару трюков.

Проверка актуальности списков

Означает что выгрузки единого реестра долго не осуществлялись или завершались неудачно.

Для отладки необходимо просмотреть /var/log/reductor/reductor.log и найти там связанные с обновлением строки (либо воспользоваться просмотром логов в веб-интерфейсе).

В реальном времени запустить выгрузку и увидеть ошибки можно с помощью команды:

service reductor update

Если в выводе имеются ошибки, связанные с сетевыми проблемами, скорее всего сервер роскомнадзора недоступен.

Полезные команды:

проверка доступности сервера ркн:

telnet vigruzki.rkn.gov.ru 80

проверка проблем в маршрутизации пакетов до сервера ркн (если команда не найдена - установите traceroute командой: yum -y install traceroute ):

traceroute -I vigruzki.rkn.gov.ru

Наличие проверенных пакетов

Означает, что в модуль фильтрации ни разу не попадал http пакет.

Обычно это бывает либо сразу после старта, либо при использовании Carbon Reductor в сети провайдера, который занимается в основном IPTV или VoIP, а интернет раздаёт паре-тройке собственных серверов, но законодательство обязало фильтровать трафик.

В противном случае возможные причины причины:

• Сбились настройки зеркала на оборудовании
• Оборудование вышло из строя
• Зеркало на оборудовании ещё не было правильно настроено
• Приём зеркала на Carbon Reductor ещё не был настроен

Наличие факта блокировки (если были попытки)

Обычно на реальной рабочей системе в продакшне в условиях текущей ситуации с фильтрацией в РФ факты срабатывания блокировки происходят постоянно.

Так что его отсутствие вполне может быть косвенным признаком какой-либо проблемы.

Для проверки - попробуйте открыть любой запрещённый сайт и запустить диагностику заново.

Если блокировка не проходит, то отладку можно провести по статье  

Наличие трафика в tcpdump

Проверяет наличие трафика идущего на 80 порт на бридже с таймаутом в 5 секунд.

См. наличие проверенных пакетов, причины обычно схожи.

Проверяем что suds установлен

Ранее имелись проблемы с использованием suds из репозиториев CentOS.

В текущей версии рабочий suds поставляется в virtualenv прямо с пакетом Carbon Reductor, так что вероятность того, что этот тест провалится крайне мала.

Тем не менее решили не удалять, так как без suds выгрузки единого реестра работать не будут.

В случае если получите эту ошибку - обязательно сообщите об этом в техническую поддержку.

Проверка свободного места на диске

Ругается на то, что на одном из дисков в выводе df занято более 85% пространства.

Поскольку Carbon Reductor обычно не занимает много места это довольно подозрительно и скорее всего место будет кончаться довольно стремительно из-за какой-либо ошибки.

Желательно отследить что именно заняло большой объём.

Проверки сетевых карт

И то и другое лечится [по этой статье]

Проверка ошибок обработки пакетов на сетевых картах

Проверяет наличие ошибок обработки входящих пакетов на сетевых картах (поле error в выводе ip -s -s link show).

Проверка дропов пакетов на сетевых картах

Проверяет изменение числа входящих dropped пакетов на сетевых картах (5 колонка /proc/net/dev).

Проверка состояния кэша https

Исправляется автоматически его занулением и перестройкой. Может занимать длительное время (около 3-4 минут).

В случае если проблема повторяется многократно - обратитесь в техническую поддержку.

Давно не отправлялась диагностика

Это относится больше к системе мониторинга. В случае если в течении двух часов сервер не отправлял в систему мониторинга отчётов о работоспособности он создаёт заявку в хелпдеске, т.к. вероятно всего сервер вышел из строя.

В заявке обычно нужна информация, выключали ли сервер/пропадал доступ в интернет или с ним действительно возникала какая-то проблема, которая привела к перезагрузке/зависанию.

Проверка числа запущенных crond

Судя по всему crond запустился дважды или более (проблема врущих pidfile например). Может случайным образом негативно сказываться на поведении периодических задач carbon reductor. Рекомендуется либо разобраться с дублирующимися crond вручную, либо просто перезагрузить сервер.

Проверка числа загруженных URL

Довольно эвристическая проверка, проверяет что число загруженных в ядро URL больше числа URL в rkn.list (http ресурсы из реестра запрещённых сайтов) минимум в 2 раза (обычно в ≈3.5).

Увеличение числа URL происходит при обработке списков (исправление ошибок, добавление различных вариаций итд) перед добавлением в ядро.

Означает либо произошедшие при загрузке URL в ядро проблемы, либо проблемы с сигнатурами.

Возможно разовое проявление при обновлении на версию 5.9.1, исправляющееся в течении часа. Если проблема повторяется - отпишите в тикет (скорее всего уже созданный в хелпдеске системой мониторинга).

Сейчас решение ниже применяется автоматически:

Вероятное решение проблемы следующее:

если

echo clear > /proc/net/ipt_reductor/block_list

возвращает ошибку "операция не позволяется", необходимо один раз перезапустить carbon reductor командой

service reductor restart

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

Проверка устаревшей версии веб-интерфейса

Если ошибка пришла один раз и больше не приходит - всё в порядке, это разовая проблема.
Если повторяется - значит при обновлении возникла проблема.

Мы добавили эту проверку в диагностику, т.к. в стартовом скрипте web-интерфейса имелась критическая ошибка, способная при неудачном сложении обстоятельств влиять на старт самого Carbon Reductor и это обновление - обязательное, а автоматического обновления у веб-интерфейса пока что не предусмотрено.
Если у вас уже есть подписка и после одной ошибки у вас всё в порядке - скорее всего у вас в хелпдеске создался alarm, если не сложно - пометьте, что его можно закрыть

Проверка содержимого собственных списков

На текущий момент проверяются:

• our.list - на то, что все записи начинаются с http://
• our.iplist - на то, что все записи являются ip-адресами и не содержат лишних пробелов.

Позже будет добавлена проверка всех остальных списков на соответствие требований к ним.

Проверка URL страницы-заглушки

На текущий момент в Carbon Reductor используется страница-заглушка http://deny.carbonsoft.ru/ на нашем удаленном веб-сервере.
Из-за загруженности нашего веб-сервера нет гарантии, что пользователи увидят эту страницу. Поэтому рекомендуем поднять веб-сервер со страницей-заглушкой в вашей локальной сети.