Нестабильная разблокировка сайтов по протоколу HTTP

[BLaDZer]

Проблема наблюдается например на сайте: rutor [точка] info и выглядит следующим образом:

• примерно 1-2 раза из 5 раз сайт открывается правильно
• примерно 2-3 раза из 5 раз сайт открывается с пустой страницей
• примерно 1-2 раза из 5 раз вместо сайта редиректит на zapret.local/****

Версия программы: 1.0 Использованные настройки:

Атака 0 уровня - fake Атака 1 уровня - disorder+fakes или просто disorder Неверный seq - отключено Автоматический подбор ttl - включено Ttl для поддельных пакетов - пусто Размер окна tcp - пусто Масштабирование окна tcp - пусто Позиция для разбиения запроса - 2 Разбивать clienthello посередине sni - отключено DNS-over-https - включено Doh сервер - [https://dns.google/dns-query] Dns сервер - 8.8.8.8

Версия ОС: Android 10, MIUI 11.0.9 (судя по всему это не принципиально "zhenyolka: у меня тоже самое c рутором, хотя остальное все работает")

И еще пара проблемных рандомных сайтов из списка заблокированных: greenlinebank [точка] info ulbit [точка] ru

Уточнения:

• с сайтами, работающими по HTTPS проблем не наблюдается
• на windows, при использовании приложения goodbyedpi проблем не наблюдается

[BLaDZer]

Проверил воспроизводится ли проблема на DPITunnel-cli - да, тоже самое (ну или почти тоже самое).

Так что с отладкой думаю должно быть попроще чем на андроид

[zhenyolka]

Нашел баг в парсере http запросов. Вероятно, проблема именно в этом.

[zhenyolka]

@BLaDZer fixed

[BLaDZer]

@zhenyolka добрый день прошу прощения что сразу не отписался. Дело в том что проблема не была исправлена ни в том релизе ни в https://github.com/zhenyolka/DPITunnel-cli/commit/41ddb174f6e3da3a14ea273c579b4eb2016f50fa

Мне открыть новый тикет или этот можно открыть снова?

[BLaDZer]

К слову браузеры себя странно ведут:

• в firefox зачастую запросы начинают отправляться на google.com кинопоиск и т.д. а не на сайт и проблема решается только через время(жизни DNS???)
  • при этом заметил что если в консоли разработчика выбрать запрос и нажать "resend" то возвращается с нужного IP адреса инфа + иногда возвращается редирект на страницу РКН (что сайт заблокирован)
  • не знаю полезно это или нет, но когда открывается левый сайт то в консоли dpitunnel пишет "Can't connect to remote server. Errno: Connection refused"
  • от приливнувшего левого IP сайта помогает перезапуск firefox или dpitunnel
• в хромиуме приколов по отправке данных на левые IP нет, но примерно 30-50% запросов возвращаются с редиректом на страницу РКН

самый сок в том что в curl не воспроизводится проблема curl 'http://rutor.info' -v -x 127.0.0.1:8080 -s 2>&1 | grep "200 OK"

при необходимости могу записать видео или сделать дамп запросов в wireshark

[zhenyolka]

@BLaDZer 1. проблема с работой именно http решена? Т.е.осталась проблема с левыми ip, правильно? Мне бы очень помогли дампы и параметры, с которыми dpitunnel запускали. Нет ли там builtin-dns? И про какую версию мы говорим, про cli или android? 2. Заглушка иногда может так появляться из-за устройства сети провайдера. Надо просто подобрать рабочие настройки.

[BLaDZer]

@zhenyolka пока дампы не приготовил - на выходных пытался разобраться в исходниках cli версии DPITunnel, а потом понял что надо еще и основы C++ подучить :)

1. Говорим про CLI версию - пока не пробовал воспроизвести на андроиде.

• пробовал и с builtin-dns и без
• пробовал и с doh и без
• уточню: что в основном вопроизводил, на одном конкретном сайте (rutor.is) и для воспроизведения нужно совершить примерно 8-25 переходов по сайту
• в общем про опции не заметил чтобы это влияло на багу - ну например такие:
  • fake
  • disorder_fakes
  • wrong_seg
• добавил в код вашего приложения чутка побольше инфы в логгер и получил следующую картину:
  • по wireshark видно что как словил багу то при любом повторном обращении к тому же сайту (в моем случае: rutor.is) - запросы начинают лететь тупо на адрес ajax.googleapis.com - это адрес одного из загружаемых JS файлов на странице
  • в логах приложения стало видно что на запрос с сервера начинает отвечать один и тот же поток приложения(я про тот, который слушает сокеты), хотя он должен был бы отработать и завершить свою работу - чего он не делает
  • примерно через 2 минуты бездействия, судя по всему, на клиентский сокет прилетает сообщение от браузера закрыть соединение (точнее что туда прилетает я не проверял так что это моя догадка) и зависший поток завершает работу - после чего запросы снова отправляются как надо. Возможно это вот оно http://kb.mozillazine.org/Network.http.keep-alive.timeout
  • причину зависания потока програмы я увы не понял, но зависает он чаще всего именно на домене ajax.googleapis.com, правда были и другие домены, возможно на других сайтах
  • видео при необходимости могу потом тоже записать

[BLaDZer]

2. пока что только записал видео на скорую руку можно смотреть вот с этого времени: https://youtu.be/kEYaJ0bGAMA?t=69

опытным путем удалось выяснить что в goodbyedpi без опции "--reverse-frag", которая идет как опция по умолчанию, проблема с периодически выскакивающими РКН-заглушками для HTTP сайтов тоже стабильно воспроизводится.

правильно я понимаю что такого в вашей программе пока нет? Можно ли попросить по возможности добавить такую классную опцию?

[zhenyolka]

@BLaDZer про первый коммент пока не могу ответить, потом просмотр внимательно и отвечу, но про второй могу. --reverse-frag это тоже самое, что и disorder. Работают одинаково.

[zhenyolka]

@BLaDZer Начнём с 2. Проблему с вылетающими заглушками смог воспроизвести. Проявляется она только с http сайтами. Что происходит: первый запрос проходит нормально и обрабатывается, а вот второй нет. Это происходит из-за того, что если быстро выполнять запросы, то они пойдут в одной tcp сессии. Это логика работы браузера, ничего с этим не сделать. Проблема в том, что dpitunnel обрабатывает только первый пакет. Можно было бы, конечно, обрабатывать все пакеты, но в таком случае возрастет нагрузка и упадет стабильность соединения, т.к. обрабатываемые пакеты отправляются частями через raw socket, и если один из них потеряется, то tcp ретрансмиссии не будет.

1. По этому пункту пока не пойму. Я предполагаю, что происходит тоже самое. Браузер начинает по какой-то причине через ту же tcp сессию общаться с совершенно другом ресурсом. Но нужны дампы трафика с этой проблемой. Я ее воспроизвести не могу.

[BLaDZer]

Это происходит из-за того, что если быстро выполнять запросы, то они пойдут в одной tcp сессии. Это логика работы браузера, ничего с этим не сделать.

@zhenyolka мне просто кажется странным что такое поведение удалось воспроизвести на goodbyedpie с определенными настройками и при этом нет проблемы с текущими настройками по умолчанию (в goodbyedpie)

По этому пункту пока не пойму. Я предполагаю, что происходит тоже самое. Браузер начинает по какой-то причине через ту же tcp сессию общаться с совершенно другом ресурсом. Но нужны дампы трафика с этой проблемой. Я ее воспроизвести не могу.

Ну там же не обязательно быстро отправлять запросы, по крайней мере если заглючило, то можно спокойно отсылать запросы раз в 20-40 секунд и будет тоже самое.

В общем задачу понял - запишу видео, постараюсь максимально чистый дамп замутить. К слову дамп данные в дампе нужны когда уже глючит или на пересечении когда норм/глюкануло?

[zhenyolka]

@BLaDZer тут еще момент, что при некоторых настройках даже в gdpi может то открываться, то нет. Это зависит от провайдера. Один раз запрос идет по одному каналу, другой по второму.

Дамп было бы интересно увидеть и в момент, и еще пару запросов, когда это уже произошло.

[BLaDZer]

что при некоторых настройках даже в gdpi может то открываться, то нет. Это зависит от провайдера. Один раз запрос идет по одному каналу, другой по второму.

@zhenyolka ничего не могу сказать при каких настройках и на каком провайдере такие проблемы - у меня на windows он работает на постоянку и тьфу-тьфу пока проблем вообще не было

Как и обещал записал видео: https://youtu.be/Cn9guWR0r0s

На нём видно как воспроизводится баг в Firefox (в другом браузере возможно не получится) и как минимум на конкретном сайте. Справа консоль dpitunnel и в квадратных скобках видно какой поток обрабатывает запрос. В момент когда случается баг - основным обработчиком для сайта rutor.info становится одни единственный поток(PID=1619), который:

1. должен был уже давно завершиться, но увы...
2. ведет не на тот адрес/сайт

Уточню: то что в браузере сайт выглядит странно и без картинок - специально их отключил чтобы было меньше запросов и меньше шума в wireshark

[BLaDZer]

Дамп трафика тоже прилагаю(в двух форматах, хз какой удобнее): dpitunnel_connection_stuck.zip

P.S. вначале захвачены пакеты с правильным IP у сайта, который должен быть "196.245.156.22", но потом запросы уже летят на "173.194.222.95"

P.S.S. проверил настройку http://kb.mozillazine.org/Network.http.keep-alive.timeout как раз по ней закрывается зависшее соединение, но по умолчанию оно стоит аж 115 секунд что как бы очень много конечно. А в каких-то приложениях которые могут быть подвержены этому багу скорее всего такой настройки уже не будет

[BLaDZer]

К слову сейчас тут https://github.com/bol-van/zapret/blob/master/docs/quick_start.txt нашел следующий текст:

Важным вопросом является вопрос о поддержке http keep alive. Отвечайте N. Если вдруг на http сайтах будут хаотические сбои типа то загружается, то заглушка или сброс, попробуйте включить поддержку keep alive.

интересно это касается указанных мною проблем или нет...