... Если вы не уверены, что страница блокируется, выполните следующие действия, чтобы получить точную информацию. # Проверьте что 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}
|