уже не важно нашёл другой и там всё ок
но сделать выводы нельзя… толи блочат mtproto толи х.з. а если и блочат то както не наглухо . коннект то есть но нет медиа.
как в “ключе” вшит левый sni не понимаю, и в этом ли дело с заглючившим…
p.s. потом ещё даже сокс нашёл рабочий/ с прогрузкой медиа, но те же звонки несмотря на настройки сквозь него не аллё
Звонки через встроенные прокси в клиенте ТГ не работают, это баг телеграма и это не фиксится без стороннего ВПН или клиента. Даже через сокс не работают, хотя написано что должны
Запущен zapret c 2 стратегиями:
1ая для ютуба (quic), 2ая для варпа (wg)
start "zapret1" /min winws.exe ^
--wf-udp=443,500 ^
--wf-raw-part=@"windivert.filter\windivert_part.wireguard.txt" ^
--filter-l7=quic --dpi-desync=fake --dpi-desync-fake-quic=files\quic.bin --new ^
--filter-l7=wireguard --dpi-desync=fake --dpi-desync-fake-wireguard=files\wg.bin
Без запрета в шарке запросы от варпа распознаются как wireguard, с запретом - как quic.
Подскажите плс, будет ли 1ая стратегия для quic применяться к варпу (раз шарк видит quic, то и запрет тоже может) ?
И как лучше: фильтровать по портам или протоколам?
На свои же фейковые пакеты Zapret срабатывать не должен, он должен игнорировать искусственно добавленные пакеты без какой-либо обработки, судя по коду nfqws.c. А шарк видит фейковые пакеты и обрабатывает их так, будто они настоящие, потому и отображает протокол, как QUIC, видя там QUIC-приманку.
Спасибо, отлично!)
Подскажите, нет ли случаем какой готовой автоматизации для разблокировки диапазонов CDN’ов? И рационально ли собирать тонны CIDR’ов в txt ipset’ы, объединенные общим белым sni для обхода?
Хочу сделать так:
это какой то позор
галку не поленились прикрутить “прокс для звонков” а по губам
вся разница что стопицот соединений к соксу во время звонка но траф таки udp на ихние turn
зато нашёл элегантное решение чтоб без vpn таки звоняло…
На чебурнете вроде имеется
Но каждый CDN имеет свои белые SNI.
Так что сложность состоит в том, что нужно применять белые SNI к своим CDN . Так-же стоит учитывать что блок у каждого CDNа свой.
Так что проще исходить от сайтов, которые пользуешься и уже оттуда танцевать (программ/игр). ТК запрет упирается в трафик, создаваемый действиями в интернете)
Прогнать dpi detector - он по множеству cdn”ов находит белые sni сразу. Сейчас ручками собрал все cidr’ы от asn’ок и запихнул в 3 ipset для разных sni. Прогнал еще раз dpi detector и почти все 16кб блоки исчезли.
Пользуюсь прокси расширением в браузере. Всё работало идеально до того момента, когда сервер этого прокси не решили перенести на хостинг OVH. Ну а дальше сами понимаете…
Смотрел через F12, оно лезет на порт 8080. Обычное https прокси. Как дурить его запретом? Пробовал в –wf-tcp и –filter-tcp к порту 443 через запятую дописывать 8080 и натравливать на IP прокси, к той стратегии, которой успешно пробиваю 1 сайт на OVH. Не помогло. А как правильно надо дурить подключение к прокси?
Фейк из белого списка отправить.
Он не продетектит l7 proto как TLS
Там применяется метод CONNECT. z1 его может опознать как http.
Если есть какие-то фильтры l7 или hostlist, то они не будут работать по SNI из TLS, а будут работать по Host: из http. См дебаг лог
Я сам не тестировал на http proxy поведение zapret, поэтому точно не скажу что будет и рецепт как сделать и тем более в какое место совать фейк. Надо экспериментировать
z2 в этом смысле лучше подходит, потому что там фильтруются отдельные пейлоады, и присунуть фейк к TLS даже под https proxy проблем нет. Без жесткой привязки к start/cutoff
У меня http прокси (с tls внутри) задурился так:
start "zapret1" /min winws.exe --debug=@z1.log ^
--wf-tcp=8080 ^
--filter-tcp=8080 --dpi-desync-any-protocol --dpi-desync-cutoff=n4 --dpi-desync=fake --dpi-desync-fooling=badsum,ts --dpi-desync-fake-tls-mod=rnd,sni=vk.com --dpi-desync-skip-nosni=0
Но почему-то стратегия немного тормозная получилась
Upd uwu подсказал, что тормозило из-за дебаг лога, лучше убрать после успешной проверки
start "zapret1" /min winws.exe ^
--wf-tcp=8080 ^
--filter-tcp=8080 --dpi-desync-any-protocol --dpi-desync-cutoff=n4 --dpi-desync=fake --dpi-desync-fooling=badsum,ts --dpi-desync-fake-tls-mod=rnd,sni=vk.com --dpi-desync-skip-nosni=0
А правильно ли будет подсовывать ему фейк ВК, если сам ВК - это далеко не OVH?
Ну у меня то не OVH) А вы можете попробовать с vk (или др. белым сни), а если не прокатит, тогда уже подбирать sni под ovh (к примеру, adme.media)
У https проксей разве есть Client Hello и SNI? Посмотрел в шарке, не нашёл. Как тогда его детектят? Тупо по обращению к “нехорошей” AS?
У моего http прокси tls под капотом, потому да, там полноценный Client Hello и Sni. Если у вас https, по идее, тоже должен быть. Так понимаю, моя стратегия у вас не сработала? Можно наверно попробовать что-то типо
--dpi-desync-any-protocol --dpi-desync-cutoff=n4 --dpi-desync=fake --dpi-desync-fooling=badsum,ts --dpi-desync-fake-unknown=какой-нибудь_пейлоад_для_http_или_tls --dpi-desync-skip-nosni=0
Думаю, да, по принадлежности ip к AS
Нет, не сработало ни то, ни это.
Может быть, попробовать др фулинг --dpi-desync-fooling= (badseq или md5sig)
Или белый сни под ваш ip подобрать
Еще можно проверить, нет ли бана по ip - в этом случае запретом не пробить
Проверить можно курлом
curl.exe -ks -m 3 -w "code=%{response_code};%{remote_ip};%{scheme};%{url.host}\n" -Z --parallel-immediate https://ваш_адрес_или_ip -o nul http://ваш_адрес_или_ip -o nul https://localhost -o nul http://localhost -o nul https://adme.media -o nul http://adme.media -o nul --connect-to ::ваш_адрес_или_ip:8080
Если в первой графе code= все по нулям, то скорее всего блок по ip
Бана по IP нет, именно 16к блок. Тестирую на простеньком сайте без стилей с парой картинок. Там текст грузится, потом 1 картинка только на половину, а остальные уже нет.
Проверить курлом не могу. Я так понял в том расширении доступ к прокси идёт ещё по логину и паролю, но я как-то пытался реверс-инженерить исходник расширения и найти их там, не смог.