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