Большое спасибо
техники OOB и tlsrec работают в России в основном только на TLS1.3
На 1.2 rdp-шный DPI сечет ответ сервера и сбрасывает
А чем отличается данная прога от TPWS? На первый взгляд функционал обеих программ одинаковый
byedpi может быть менее стабильным, чем tpws, не содержит некоторых опций, таких, как hostlist, bind-wait и пр. Но он позволяет совершать более запутанные аттаки, такие как fake, отсылка нескольких oob байт подряд, разбиение по нескольким позициям.
Каким образом делается вывод, что ‘не удалось’ ?
В tpws для этого сечется несколько вариантов :
- RST, пришедший в ответ на первый запрос с хостом.
- HTTP редирект, пришедший в ответ на первый запрос с хостом, на глобальный адрес
с доменом 2 уровня, не совпадающим с доменом 2 уровня оригинального запроса. - закрытие соединения клиентом после отправки первого запроса с хостом, если не было на него
ответа со стороны сервера. Это обычно случается по таймауту, когда нет ответа (случай “зависание”).
Окей, первые 2 варианта можно обыграть как-то. Придется держать входящий конект и переподключаться несколько раз, чтобы попробовать новый вариант. Сложновато, но реализуемо.
Но как быть с вариантом 3 ? Это очень распространенный вариант.
Броузеры долго висят в ожидании ответа. Придется вводить какой-то более короткий таймаут, чтобы самому попробовать несколько вариантов, оставляя броузер висеть в это время.
Но сколько ждать ?
IP сайта кэшировать не есть гуд. Они могут скакать и быть множественными. Может лучше домен ?
И что в случае перезапуска ? Нигде не сохраняется результат ?
Пока обрабатывается только RST на первый запрос.
Да, так я и реализовал.
В первую очередь я хотел решить проблему поломки сайтов из-за tlsrec/oob/disorder, когда сервер сразу сбрасывает соединение. Пока не уверен, нужно ли добавлять обработку заморозки соединения, т.к. высока вероятность ложного срабатывания - высокий пинг, подвисание всей сети, медленный wifi на расстоянии, сайт временно не доступен.
IP сохранять есть смысл при использовании --redirect, чтобы обходить блокировки по IP, когда под ним могут быть и другие невинные сайты. Могут быть случаи невозможности определения домена (запутываются и другие протоколы, ESNI). Но да, IP может быть много, возможно добавлю кеширование доменов, с возможностью добавление IP, если нет домена.
Не сохраняется, и сами значения в кеше тоже валидны лишь несколько часов. Это сделано для того, чтобы кеш был актуальным, например, при чередовании провайдеров или при масштабных сбоях/временных блокировках, которые в последнее время часто случаются. При обработке только RST, новый перебор каждые несколько часов/суток некритичен, т.к. не занимает много времени.
Без этого на многих провайдерах затея полностью теряет смысл
curl --max-time 5 https://rutracker.org
curl: (28) Connection timed out after 5000 milliseconds
curl --max-time 20 http://bbc.com
curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received
sknt и rostelecom SPB ведут себя так.
Он даже не удосуживается огрызнуться RST. Он отмораживается молча. Вот еще. Буду я на тебя ресурсы тратить. Не дождешься, виси там себе, тупи сколько влезет
На http самая типичная реакция - не RST, а именно редирект
Чредование провайдеров это смена wifi или wifi/cell ?
Так оно может случаться куда быстрее нескольких часов. Это скорее надо как-то детектить, если очень уж хочется.
Таблица маршрутизации доступна и без рута. Можно смотреть default gateway. ip4 и ip6
Можно даже не заморачиваться с netlink. Есть /proc/net/route и /proc/net/ipv6_route
Если поменялся gateway, то сбрасывать кэш. Возможно, стоит смотреть не полностью эту запись, а только название интерфейса default gateway, чтобы различать cell и wifi. Ведь сотовик может дать разные подсети при каждом подключении. Тут хорошо бы потестить на разных операторах, подергать подключение.
Еще лучше - держать разные кэши для разных подключений. Потому что скакать оно может иногда довольно часто.
Аппарат перемещается, то входит в зону wifi, то выходит, плохой прием wifi или cell
На таких можно делать наоборот - запутывать все подключения, а исключать лишь поломанные сайты (которые, в основном, сразу присылают RST):
./ciadpi --tlsrec 3+s --auto
Это так, сходу привел в пример, как одна из причин устаревания кеша, особо данный случай не расматривал, но спасибо за идею. Кажется, подобное лучше реализовывать не внутри прокси, а снаружи (на android за это может отвечать приложение). Наверняка на разных провайдерах будут работать разные методы, тут скорее нужны профили и переключение между ними. Например, на мобильном хорошим вариантом будет обнаруживать блокировки, а на wifi, где соединение замораживается, обнаруживать только поломки. тогда нужно будет перезапускать прокси с разными параметрами для разных сетей.
Все же добавлю таймаут, но включаться он будет на усмотрение пользователя (не везде это нужно). Думаю оптимально будет 2-3 секунды, но если увеличивать его, то желательно и время жизни кеша увеличить.
В винде --fake невозможен? Похоже, это единственное, что может пробить моего провайдера.
goodbyedpi умеет
В byedpi он не поддерживается, но, возможно, в теории, его можно как-то реализовать из пользовательского пространства, хотя я сильно сомневаюсь.
Что насчёт tlsrec или oob?
ciadpi --oob 10+s --tlsrec 1+s
Да, это возможно, используя TransmitFile. Возможно, скоро добавлю поддержку --fake и на Windows
О, работает! Я пробовал эти параметры, но с другими числами. Гран мерси!
Вообще, у меня GDPI давно стоит, но прокси мне удобнее. Особенно с новым параметром --auto.
Кстати, у меня категорически отказывается работать ciadpi на портах из первых тысяч, хотя порты свободны. Поставил 10800, работает, но странно это.
Какая ошибка выводится?
А вот и тестовая версия:
byedpi-3da60eb.zip (51,8 КБ)
Ограничения те же, что и на Linux
10013
5000+ ставил, работает.
ciadpi --auto --timeout 3 --oob 8+s --tlsrec 1+s --fake 3+s --ip 127.0.0.1 --port 10800
В общем, так всё открывается вроде, что нужно. Кроме rutor.info, hdrezka.ag, но туда особо и не хожу, просто проверял. Я так понимаю, это просто сами сайты ломаются? Что интересно, Instagram через GDPI открывается только с IP 157. в hosts, а с byDPI без разницы IP.
Этот не поддерживает TLS 1.3. Техники обхода без фейков могут не работать на TLS 1.2, поскольку сечется ответ сервера
Точно, поэкспериментил на других таких сайтах, типа exler.ru. А значит, fake у меня вообще не работает? Убрал его, вернул, что есть, что нет.
Смотрите шарком tcp port 443.
Методика отсылки фейка в byedpi потенциально ненадежна, а может просто не обходится таким методом у вас.
А еще фейк требует какого-то ограничительного фактора. Им может выступать TTL. TTL нужно подбирать как минимально работающее значение на вашем провайдере