Ошибки в диагностике

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

# Проверьте то, что у Carbon Reductor имеется доступ в интернет и его никуда не редиректит. Возможна ситуация - сервер добавлен в биллинговую систему как абонент и через некоторое время он уходит в отрицательный баланс и все его запросы редиректятся на страницу-заглушку или просто отбрасываются.
# Проверьте [настройки|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51380299] выгрузок единого реестра
# Проверьте то, что [в системе настроен правильный часовой пояс|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51380678]
# Проверьте то, что у вас работает DNS (достаточно ping \-c 1 ya.ru)


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

Для приёма зеркала трафика с коммутатора нужно иметь созданный бридж, создать его можно с помощью [мастера настройки сети|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51380295] (в этой же статье описано как настроить сеть для приёма трафика с маршрутизатора).


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

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

{code}
service reductor restart
service network restart
{code}

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

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

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

{code}
service reductor restart
{code}

Если он пишет ошибки при старте, может помочь [эта статья|reductor5:Ошибки при старте].

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

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

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


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

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

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


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

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


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

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

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

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

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

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

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

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


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

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

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

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


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

*Внимание:* проверьте используемую вами версию Carbon Reductor, если меньше 618 194 - срочно обновитесь.

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

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

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

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

{code}
telnet vigruzki.rkn.gov.ru 80
{code}
проверка проблем в маршрутизации пакетов до сервера ркн (если команда не найдена - установите traceroute командой: yum \-y install traceroute ):

{code}
traceroute -I vigruzki.rkn.gov.ru

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

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

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

* Сбились настройки зеркала на оборудовании
* Оборудование вышло из строя
* Зеркало на оборудовании ещё не было правильно настроено
* Приём зеркала на Carbon Reductor ещё не был [настроен|reductor5:Зеркалирование трафика]


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

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

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

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

Если блокировка не проходит, то отладку можно [провести по статье|reductor5:Установили и не блокируется]  


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

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

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


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

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

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

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

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


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

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

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

Желательно отследить [что именно заняло большой объём|reductor5:Как чистить место на жёстком диске].

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


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

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


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

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

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

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

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

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

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

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

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

если

{code}
echo clear > /proc/net/ipt_reductor/block_list
{code}
возвращает ошибку "операция не позволяется", необходимо один раз перезапустить carbon reductor командой

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

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

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

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

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

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

Позже будет добавлена проверка всех остальных списков на соответствие [требований к ним|reductor5:Свои списки. Черные списки. Белые списки].

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

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

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

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

P.S: Ошибка выводится однократно при автоматической смене адреса страницы с helpdesk.carbonsoft.ru/deny, который скоро перестанет быть доступным, на deny.carbonsoft.ru