Вы просматриваете старую версию данной страницы. Смотрите текущую версию.
Сравнить с текущим |
просмотр истории страницы
Если вы не уверены, что страница блокируется, выполните следующие действия, чтобы получить точную информацию.
- Проверьте что URL находится в списке /usr/local/Reductor/lists/http.load, в случае с https проверьте, что ip, в который разрешается доменное имя из url, присутствует в списке https.resolv
- Если он там отсутствует - проверьте что он находится в выгрузке:
grep -o "вставьте_сюда_url" /usr/local/Reductor/reductor_container/gost-ssl/php/dump.xml
- Проверьте, что с сервера Carbon Reductor доступен компьютер пользователя (ping, arping, в идеале route через scope)
- Проверка стабильного попадания трафика от абонента до этой страницы в сетевую карту редуктора (смотрите "пример как ловить GET запросы абонента")
- Проверьте, также что он хотя бы несколько раз подряд попал на сервер (иными словами что проблема не плавающая) (Пример как ловить GET запросы абонента)
- Определите, сработало ли match правило carbon reductor или нет (увеличились ли счётчики у правила):
iptables -xnvL FORWARD
- Проверьте на сервере с reductor отправку RST пакета с самого сервера. (Пример как ловить отправку tcp-сегментов c RST флагом абоненту)
- Проверьте, что он успешно дошёл до тестового абонентского компьютера, запустив на нем wireshark или tshark
- Ограничьте фильтрацию одним этим URL (чтобы абоненты не инкрементировали счётчики правила, а вы не делали на основе этого ложные выводы).
Пример как ловить GET запросы абонента
tshark -n -i <интерфейс-зеркало> tcp dst port 80 or 443 -R "tcp.flags.push==1" and src host ip_addr_of_testing_pc
Пример как ловить отправку с сервера tcp-сегментов c RST флагом абоненту
tshark -n -i <исходящий интерфейс> tcp src port 80 or 443 -R "tcp.flags.reset==1" and dst host ip_addr_of_testing_pc
_правильная_версия_статьи_должна_выглядеть_так
- проверка особенного поведения браузера или ос абонента (возможно формирование не совсем стандартного запроса)
- 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 (отключение фильтрации для всех и всего кроме них)