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

{toc}

h1. {color:#ff0000}Проверка настроек страницы-заглушки.{color}

{color:#ff6600}{*}Внимание{*}{color}: большая часть тикетов будет создана "мимо" диагностики и мониторинга, возможно в них автоматически будет добавлен ошибочный комментарий о том, что поступили данные о том, что проблема исчезла. Не обращайте на него внимания.

Используется страница-заглушка CarbonSoft, нужно настроить собственную страницу заглушку.

Как это сделать? Вариантов несколько:

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


Чтобы АС ревизор её успешно распознавал, следуйте инструкции:

[https://github.com/carbonsoft/reductor_blockpages]

1. URL страницы-заглушки
{panel}[http://vashazaglushka.ru/deny.html]{panel}
2. IP для DNS-ответов
{panel}IP-адрес веб сервера, на котором расположена страница заглушки{panel}

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


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

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

В этом же разделе изменить два поля:


1. URL страницы-заглушки

{panel}[http://IP\-|http://IP-]редуктора/block.html{panel}

2. IP для DNS-ответов

{panel}
IP-редуктора
{panel}



Последний шаг - перезапустить Reductor

{panel}
service reductor restart
{panel}



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

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

Этот тикет возможно автоматически пометится как решённый.

h1. Проверка того, что указан IP ревизора.

Требуется указать IP-адрес АС Ревизор в menu.

В консоли запускаем команду menu

Переходим в раздел "Настройка алгоритма фильтрации"

!Снимок экрана от 2016-12-30 15-20-46.png|border=1!

Затем в подменю "IP адрес ревизора или сателлита"

!Снимок экрана от 2016-12-30 15-22-58.png|border=1!

И прописываем в данном поле IP адрес ревизора или сателлита.

!Снимок экрана от 2016-12-30 15-23-11.png|border=1!

Нажимаем <OK> и выходим из меню, при этом сохраняем настройки.

!Снимок экрана от 2016-12-30 15-23-22.png|border=1!

И последний шаг - перезапустить Reductor

{code}
service reductor restart
{code}

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

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

# Проверьте то, что у Carbon Reductor имеется доступ в интернет и его никуда не редиректит. Возможна ситуация - сервер добавлен в биллинговую систему как абонент и через некоторое время он уходит в отрицательный баланс и все его запросы редиректятся на страницу-заглушку или просто отбрасываются.
# Проверьте [настройки|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51380299]&nbsp;выгрузок единого реестра
# Проверьте то, что [в системе настроен правильный часовой пояс|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 - срочно обновитесь.


Означает что выгрузки единого реестра долго не осуществлялись или завершались неудачно (dump.xml старее 6 часов = ошибка).

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

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

{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
{code}


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

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

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

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

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


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

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

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

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

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


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

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

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


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

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

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

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

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


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

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

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

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


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

И то и другое лечится [по этой статье|Потери на сетевых картах, задержки в обработке и как с ними бороться]

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


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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

если

{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

h1. Проверяем отсутствие NetworkManager

NetworkManager запрещено устанавливать и использовать на сервере с Редуктором, потому что он занимается менеджментом сетевых подключений. Как результат - может привести к проблемам со стартом сетевых интерфейсов, настроенных с помощью мастера настройки сканирования зеркала трафика, да и для интерфейсов для менеджмента/выхода в инет/редиректов тоже.

В результате - пропуски блокировок и выгрузок. Лучшее решение - его удаление:

{code}service NetworkManager stop
yum -y erase NetworkManager
service network restart{code}

И настроить сеть по [инструкции|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51380295].


h1. Проверяем автоматический старт сервисов

Причины возникновения: отключение автостартов nginx, reductor, reductor_web, crond. Для корректной работы Редуктора все эти сервисы должны быть включены.
В диагностике выводится какие конкретно сервисы были выключены в автостарте (должны быть включены точно на level-ах 3, 4 ,5)

Включить нужно так:

{code}
chkconfig --level 345 nginx on
chkconfig --level 345 reductor_web on
chkconfig --level 345 reductor on
chkconfig --level 345 crond on
{code}

h1. Проверяем используемую версию ядра Linux

Самое старое ядро Linux на котором гарантированно работают все возможности Carbon Reductor: 2.6.32-573. Рекомендуемое для использования - 2.6.32-642.

На ядрах более старых версий встречались проблемы с работой модулей DNS и редиректа для IPv6.

Диагностика автоматически устанавливает последнее доступное ядро Linux, вам остаётся только перезагрузить сервер (автоматически это сделать было бы не самым лучшим решением)