... Если вы не уверены, что страница блокируется, выполните следующие действия, чтобы получить точную информацию.
# Проверьте что URL находится в списках (есть в реестре, есть после разбора реестра, есть после обработки списков) :
{code}
chroot /app/reductor /usr/local/Reductor/bin/url_info.sh "вставьте_сюда_ваш_url"
{code}
# Проверьте, что с сервера Carbon Reductor доступен компьютер пользователя (ping, arping)
# Проверка стабильного попадания трафика от абонента до этой страницы в сетевую карту редуктора (смотрите ниже "Пример как ловить GET запросы абонента")
Для тестирования https ресурсов нужно убедиться, что включена [фильтрация DNS|reductor5:DNS] и dns-запросы абонента попадают в сетевую карту редуктора (смотрите ниже "Пример как ловить DNS запросы абонента")
# Определите, сработало ли match правило carbon reductor или нет (увеличились ли счётчики у правила):
{code}
iptables -xnvL FORWARD
{code}
По возможности ограничьте фильтрацию одним этим URL, чтобы абоненты не инкрементировали счётчики правила, а вы не делали на основе этого ложные выводы.
# {color:#ff0000}(только для http){color} Проверка срабатывания редуктора. По умолчанию выключена, включается в menu \-> Настройка алгоритмов фильтрации \-> Логировать срабатывания.
{code}
chroot /app/reductor tail -f /var/log/reductor/forbidden.log
{code}
# Проверьте на сервере с reductor отправку http-редиректа и/или tcp-RST пакета с самого сервера. (смотрите ниже "Пример как ловить отправку http-редиректов и/или tcp-RST абоненту")
Для тестирования https ресурсов нужно ловить dns-ответы редуктора абоненту (смотрите ниже " Пример как ловить DNS ответы редуктора абоненту")
# Проверьте, что он успешно дошёл до тестового абонентского компьютера, запустив на нем wireshark или tshark.
# Если пакет не доходит до тестового абонента, проверьте не блокируются ли ответы фаерволлом на шлюзе.
h2. Пример как ловить GET запросы абонента
{code}
chroot /app/reductor/
{code}
|
