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

В нормальном настроенном состоянии 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 адреса на интерфейсе, куда приходит зеркало. Так что обычно для того чтобы это исправить достаточно выполнить команды

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 и найти там связанные с обновлением строки (либо воспользоваться просмотром логов в веб-интерфейсе).

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

Ознаает, что в модуль фильтрации ни разу не попадал 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