Проверка блокировки конкретной страницы

Версия 5 oleg
на окт 05, 2015 13:11.
<< Изменения с 4 по 5
по сравнению с
Текущая Технический писатель
на мар 27, 2017 17:39.
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (19)

просмотр истории страницы
Если вы не уверены, что страница блокируется, выполните следующие действия, чтобы получить точную информацию.

# Проверьте что URL находится в списке /usr/local/Reductor/lists/http.load, в случае с https проверьте, что ip, в который разрешается доменное имя из url, присутствует в списке https.resolv
# Если он там отсутствует - проверьте что он находится в выгрузке:&nbsp;
# Проверьте что URL находится в списках &nbsp;(есть в реестре, есть после разбора реестра, есть после обработки списков)&nbsp;:&nbsp;
{code}
grep -o "вставьте_сюда_url" /usr/local/Reductor/reductor_container/gost-ssl/php/dump.xml
/usr/local/Reductor/bin/url_info.sh "вставьте_сюда_ваш_url"
{code}
# Проверьте, что с сервера Carbon Reductor доступен компьютер пользователя: пользователя (ping, arping)
{code}
ping <ip адрес абонентского компьютера>
{code}
# Для начала проверьте, что трафик вообще попадает на сервер:
{code}
tcpdump -nvi <интерфейс-зеркало> dst port 80 or 443
{code}
# Проверьте, также что он хотя бы несколько раз подряд попал на сервер (иными словами что проблема не плавающая) (Пример как ловить GET запросы абонента)
# Проверка стабильного попадания трафика от абонента до этой страницы в сетевую карту редуктора (смотрите ниже "Пример как ловить GET запросы абонента")
Для тестирования https ресурсов нужно убедиться, что включена [фильтрация DNS|reductor5:DNS]&nbsp;и dns-запросы абонента попадают в&nbsp;сетевую карту редуктора (смотрите ниже "Пример как ловить DNS запросы абонента")
# Определите, сработало ли match правило carbon reductor или нет (увеличились ли счётчики у правила):
{code}
iptables -xnvL FORWARD
{code}
# Проверьте на сервере с reductor отправку RST пакета с самого сервера. (Пример как ловить отправку tcp-сегментов c RST флагом абоненту)
По возможности ограничьте фильтрацию одним этим URL, чтобы абоненты не инкрементировали счётчики правила, а вы не делали на основе этого ложные выводы.
# {color:#ff0000}(только для http){color} Проверка срабатывания редуктора. По умолчанию выключена, включается в menu \-> Настройка алгоритмов фильтрации \-> Логировать срабатывания.
{code}
tail -f /var/log/reductor/forbidden.log
{code}
# Проверьте на сервере с reductor отправку http-редиректа и/или tcp-RST пакета с самого сервера. (смотрите ниже "Пример как ловить отправку http-редиректов и/или tcp-RST абоненту")
Для тестирования https ресурсов нужно ловить dns-ответы редуктора абоненту (смотрите ниже " Пример как ловить DNS ответы редуктора абоненту")
# Проверьте, что он успешно дошёл до тестового абонентского компьютера, запустив на нем wireshark или tshark.
# Ограничьте фильтрацию одним этим URL (чтобы абоненты не инкрементировали счётчики правила, а вы не делали на основе этого ложные выводы).
# Если пакет не доходит до тестового абонента, проверьте не блокируются ли ответы фаерволлом на шлюзе.

h2. Пример как ловить GET запросы абонента

{code}
tshark -n -i <интерфейс-зеркало> tcp dst port 80 or 443 -R "tcp.flags.push==1" and src host <ip_addr_of_testing_pc>
{code}

h2. Пример как ловить отправку с сервера tcp-сегментов c RST флагом http-редиректов и/или tcp-RST абоненту
{code}
tshark -n -i <исходящий интерфейс> tcp src port 80 or 443 -R "tcp.flags.reset==1||http" and dst host <ip_addr_of_testing_pc>
{code}

h1. \_правильная_версия_статьи_должна_выглядеть_так
h2. Пример как ловить DNS запросы абонента
{code}
tcpdump -ni <интерфейс-зеркало> udp dst port 53 and src host <ip_addr_of_testing_pc>
{code}
Для конкретного домена:
{code}
tshark -nn -i <интерфейс-зеркало> udp dst port 53 -R "dns.qry.name==www.betfaircasino.com"
{code}

# проверка особенного поведения браузера или ос абонента (возможно формирование не совсем стандартного запроса)
# url_info на страницу (есть в реестре, есть после разбора реестра, есть после обработки списков)
# доступность абонента с редуктора (ping, arping, в идеале route через scope)
# проверка стабильного попадания трафика от абонента до этой страницы в сетёвку редуктора (tshark, curl)
# проверка стабильного попадания трафика от абонента до этой страницы в iptables FORWARD (счётчик правила iptables \-I FORWARD \-s абонент \-d сайт \-p tcp \--dport 80)
# проверка срабатывания редуктора (см. dmesg \| grep blocked итд)
# проверка ухода редиректа и RST с редуктора до абонента (tcpdump \-nni интерфейс_для_rst)
# проверка того, что редирект и RST стабильно принимаются абонентом (tshark / wireshark на абоненте)
# отладка фильтрации на 1 абоненте и 1 url (отключение фильтрации для всех и всего кроме них)
h2. Пример как ловить DNS ответы редуктора абоненту
{code}
tcpdump -ni <исходящий интерфейс> udp src port 53 and dst host <ip_addr_of_testing_pc>
{code}
Для конкретного домена:
{code}
tshark -nn -i <исходящий интерфейс> udp src port 53 -R "dns.qry.name==www.betfaircasino.com"
{code}