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

Skip to end of metadata
Go to start of metadata
Вы просматриваете старую версию данной страницы. Смотрите текущую версию. Сравнить с текущим  |   просмотр истории страницы

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

  1. Проверьте что URL находится в списке /usr/local/Reductor/lists/http.load, в случае с https проверьте, что ip, в который разрешается доменное имя из url, присутствует в списке https.resolv
  2. Если он там отсутствует - проверьте что он находится в выгрузке: 
    grep -o "вставьте_сюда_url" /usr/local/Reductor/reductor_container/gost-ssl/php/dump.xml
    
  3. Проверьте, что с сервера Carbon Reductor доступен компьютер пользователя:
    ping <ip адрес абонентского компьютера>
    
  4. Для начала проверьте, что трафик вообще попадает на сервер:
    tcpdump -nvi <интерфейс-зеркало> dst port 80 or 443
    
  5. Проверьте, также что он хотя бы несколько раз подряд попал на сервер (иными словами что проблема не плавающая) (Пример как ловить GET запросы абонента)
  6. Определите, сработало ли match правило carbon reductor или нет (увеличились ли счётчики у правила):
    iptables -xnvL FORWARD
    
  7. Проверьте на сервере с reductor отправку RST пакета с самого сервера. (Пример как ловить отправку tcp-сегментов c RST флагом абоненту)
  8. Проверьте, что он успешно дошёл до тестового абонентского компьютера, запустив на нем wireshark или tshark
  9. Ограничьте фильтрацию одним этим 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

_правильная_версия_статьи_должна_выглядеть_так

  1. url_info на страницу
  2. доступность абонента с редуктора (ping, arping, в идеале route через scope)
  3. проверка стабильного попадения трафика от абонента до этой страницы в сетёвку редуктора
  4. проверка стабильного попадения трафика от абонента до этой страницы в iptables FORWARD
  5. проверка срабатывания редуктора (см. dmesg итд)
  6. проверка ухода редиректа и RST с редуктора до абонента
  7. проверка того, что редирект и RST стабильно принимаются абонентом
  8. отладка фильтрации на 1 абоненте и 1 url (отключение фильтрации для всех и всего кроме них)
Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.