Перестал работать, ничего не трогали

Skip to end of metadata
Go to start of metadata

Иногда при проверке утилитой Роскомнадзора возникает проблема с тем, что часть адресов не блокируется. Причины у этого бывают разные и здесь мы попробуем описать как их найти и решить эту проблему.

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

1. Сколько процентов URL доступно в отчёте утилиты РКН

Если заблокировано 50 - 100% - явно имеется какая-то проблема в работе сервера. Скорее всего встроенная диагностика это обнаруживает, но её отчёты не были замечены (например указан неправильный адрес почты/её не читали/у carbon reductor ограничен доступ в интернет). Запустить её можно с помощью команды:

/usr/local/Reductor/bin/diagnostic.sh

Если диагностика выводит ошибки - все их нужно исправить и только после этого продолжать тестирование утилитой.

Если заблокировано 3 - 50%, то возможно дело в изменённых настройках Carbon Reductor или белых списках. Постарайтесь вспомнить что меняли в последнее время, если до этого всё работало.

Если заблокировано менее 3% - скорее всего ошибка связана со специфичными URL, обратитесь к пункту 3 данной статьи.

2. Работает ли фильтрация в браузере

Если фильтрация вручную работает, возможно не срабатывает обнаружение блокировки в утилите РКН.

На всякий случай стоит проверить фильтрацию с разных компьютеров, чтобы исключить частные проблемы конкретной машины.

Проверьте не блокируются ли ответные пакеты фаерволлом на шлюзе.

Если есть возможность, проверьте фильтрацию с разных браузеров / OS. Иногда они генерируют разные GET-запросы и корень проблемы кроется в этом.

Пронаблюдать за этим на Carbon Reductor можно с помощью следующей команды (подставьте нужный интерфейс вместо eth1):

tshark -n -i eth1 tcp dst port 80 -R "tcp.flags.push==1" and src host IP_адрес_тестовой_машины

3. Пропускаются одни и те же сайты или разные?

3.1 Разные сайты

Если пропускаются разные сайты, то скорее всего проблема либо в потере пакетов, неподходящих настройках сетевых карт (малый буфер сетевых карт), плохом качестве сетевых карт, либо в высокой нагрузке на процессор, либо в промежуточном оборудовании. Стоит прочитать статью: Потери на сетевых картах, задержки в обработке и как с ними бороться

Постарайтесь посмотреть на коммутаторе с зеркалом трафика данные об ошибках на интерфейсе к которому подключен сервер Carbon Reductor. 

3.2 Одни и те же

Если же не блокируются одни и те же страницы, то воспользуйтесь статьёй: [reductor:Проверка блокировки конкретной страницы]

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

Возможно у не блокируемых страниц имеется что-то общее - какой-нибудь спецсимвол, который может по разному экранироваться разными библиотеками для работы с URL или что-то ещё. Если заметите - сообщите об этом в заявке, это сократит время её решения.

4. Один и тот же сайт то блокируется то не блокируется

Опять же - это проблема с плавающей блокировкой и причины скорее всего те же самые, что и в пункте 3.1 этой статьи.

5. Насколько актуальна используемая вами версия Carbon Reductor?

Проверьте что она актуальная, если нет - нужно обновиться до последней версии:

5.1 CentOS 6

Запустите команду menu

Обновление Carbon Reductor...

Обновить Carbon Reductor

5.2 Carbon Reductor встроен в Carbon Billing 4 или Carbon AS 4

Узнать актуальную версию Billing / AS можно на этой страничке:

https://github.com/carbonsoft/cb4reductor

Тем не менее мы рекомендуем переходить на Carbon Reductor, установленный на CentOS 6 на отдельном сервере, в новых версиях Billing 4 / AS 4 имеются средства для ускоренного переезда (настройка зеркала на IP Carbon Reductor одним параметром в меню).

6. Какой протокол не фильтруется, http или https?

В случае с https - проблема может быть в том, что получает Carbon Reductor в ответ от DNS сервера при резолве доменов https-ресурсов.
Также проверьте, что у вас включена фильтрация по https и использование nslookup в Настройках алгоритма фильтрации в консольном menu.
Возможно сервер не справляется с большим количеством запросов. В таком случае поможет опция в настройках алгоритма фильтрации: "Таймаут для nslookup", увеличенная с 0.1 до минимально возможного значения, при котором DNS справляется с запросами.

Вторая возможная причина - DNS используемый Carbon Reductor даёт другой IP при резолве, по сравнению с DNS используемым тестовой машиной.

Сравнить это можно с помощью утилиты nslookup.

Обычно эта проблема решается  использованием google dns (8.8.8.8) в качестве основного.

7. А зеркало трафика "влезает" в сетёвку?

В случае если у вас both mirror, может оказаться что трафик просто напросто не может быть передан поскольку его больше, чем максимальная пропускная способность сетевой карты (например rx 700мбит/с, tx 450мбит/с), в таком случае возможны потери нужных для обработки пакетов.

Здесь несколько вариантов, в зависимости от возможностей оборудования, с которого снимается зеркало трафика:

  1. Оставить в зеркале только исходящий от абонентов трафик
  2. Отфильтровать трафик на свитче по портам: 80, 443 и другие, необходимые для фильтрации.
  3. Отфильтровать трафик на свитче по tcp-флагам.
  4. Отфильтровать трафик на свитче по длине пакетов.
  5. Разбить зеркало трафика на несколько сетевых карт, например вместо зеркала 1-20 портов в 21 сделать 1-10 в 21, а 11-20 - в 22. На Carbon Reductor соответственно добавить ещё одну сетевую карту.
  6. Поменять свитч и сетевую карту в Carbon Reductor на более производительные (например с 1гбит/с на 10гбит/c).

Насчёт 4го варианта - на самом деле это просто пришло в голову, но скорее всего будет иметь неплохое действие. Если есть возможность, потребность и желание поэкспериментировать с ним - отпишите об этом в хелпдеск, мы с удовольствием поможем с этим.

Посмотреть какой объём трафика прилетает на сетевую карту можно следующим образом:

ip -s -s link show dev eth1
sleep 1
ip -s -s link show dev eth1
sleep 1
ip -s -s link show dev eth1

Вычислите разницу в поле RX bytes, если она близка к потолку проходимости сетевой карты - возможно проблема именно в этом.

Более правильным способом проверки является просмотр статистики по порту на свитче, там должно быть поле, называющееся в духе outgoing drops. Если оно растёт - нужно снижать объём зеркалируемого в этот порт трафика любым из способов выше.

8. А не блокируемые сайты есть в реестре?

Возможно у вас устаревшие, либо наоборот слишком новые списки. В поставке Carbon Reductor идёт утилита - /usr/local/Reductor/bin/url_info.sh. Пример вызова:

# /usr/local/Reductor/bin/url_info.sh http://lostfilm.tv
# в http.load
http://lostfilm.tv
# ip address
104.28.16.79
104.28.17.79
# реестр (целиком)
http://www.lostfilm.tv
# реестр (домен)
lostfilm.tv

В принципе можете её скопировать и модифицировать под себя. Взять её код можно здесь:

https://github.com/carbonsoft/carbon_scripts/blob/master/reductor_url_info.sh

Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.