У меня на многих мелкосайтах часть страниц/скриптов/картинок грузится на сколько-то процентов потом останавливаются. Запрет с этим помогает? Это вообще лечится без прокси?
Например эта страница грузится процентов на 30 - https://www.dnsleaktest.com/ana/matomo.js
Реализация 16кб блока или его аналог. Так-же может быть там частично блок по cidr/ip или тригер на блок к ресурсу
При условии что пинг/курл и другие способы диагностики доступности ресурса проходят. То поможет.
Если там блокировка по cidr/ip, то прокси и другие способы редиректа трафика
Так что нужно проверить например конкретно для этой страницы? Через blockcheck ее гонять? Через курл она также как в браузере отдает ответ до середины и виснет. Пингуется домен нормально, dnsleak вроде не в черных списках.
изучайте сборки. на акамаи скорее всего белый список доменов как и на клаудфлер
По моему это логично. Quic ускоряет загрузку видео. Соответственно если в браузере она отключена то видео будут дольше грузиться или вообще не загрузятся. Такие эксперименты я не проводил. У меня всегда по default -у стоял.
Если известен какой-нибудь домен akamai из белого списка, то буду благодарен, если поделитесь в лс)
dnsleaktest.com оказывается не akamai cdn, а vps linode (от akamai). с первой же попытки угадал - adobe.com в белом списке и dnsleak test прогрузился (ток я проверял через curl, запретом не пользуюсь)
петушары добрались до телеги на проводе спб и стали шейпить скорость
беглый осмотр дал - что в принципе нет clienthello и т.п. в обмене - видать пидоры выучили ихние ip
и всё равно не покидает ощущение что можно и без vpn обдурить - IP_ID вроде то что надо - но без примера не понять
- наверно и desync-any-protocol необходимо…
у когонибудь выходило чтонибудь путное?
замедление по айпи адресам, проверял через кастом sni в curl
curl -k -o /dev/null https://CUSTOMSNI/tlinux/tsetup.6.4.2.tar.xz -H "Host: td.telegram.org" --connect-to ::td.telegram.org
ну это я и так понял - сайт петушары тоже тормозят - вопрос есть ли в природе варианты пробивки шейпера ip ?
У меня пока не вижу замедления. Видео играются в телеге с компа нормально.
Или замедление не столь существенное.
Если не брать веб часть, то уязвимости у телеги всего 2 : стандартная подсеть и протокол mtproto, который обнаруживается по первому пакету, на который нужно выполнить AES, чтобы вскрыть сигнатуру. nfqws2 ее вскрывает и обнаруживает протокол mtproto. Его можно попытаться дурить как любой tcp протокол. Но сначала надо бы прогнать tcp через сторонний сервер, чтобы понять протокол обнаруживается или IP
Если там стоит тупое rule на subnet blabla/cidr tcp shape, то совсем автономных вариантов нет.
ясно
curl кажет - что веб часть на 512к режут или чуть меньше - в приложухе же сразу заметно даже на этапе загрузки - в видео и подавно - значит тока начали разливать правило…
в регионах по cidr уже месяца 2 замедляют
что может быть не так и в какую сторону копать?
ситуация:в winws миллион из миллиона попыток всё норм а на роутере полный рандом с тойже стратегией для http80
причём если hostfakesplit и fakesplit и вовсе лезет заглушка то для multidisorder и multisplit заглушки нет но коннект виснет ни туда ни сюда белый экран пока стоп-рефреш не нажать
проца-памяти рутеру не хватает или таки раз разные архитектуры то чтото не аллё? + если winws всё сам делает - на рутере ещё ж и ручонками iptables нужно морщить… тоже может тут затык?
p.s. нет не в ttl =без него стратегии
p.p.s с 443 всё норм везде
У телеги свой собственный AS, так что её легко могут блокнуть/замедлить по CIDR. Я так понимаю в этом случае запрет будет бесполезен? Только проксирование?
Да, но прежде чем утверждать это, надо завернуть mtproto через сторонний хост. И только если поток 1:1 на нем не блокнется, то это cidr. Хотя не исключен вариант и cidr+mtproto.
Тогда дурить на стороннем, если задурится , а не AS телеги нет - блок по ip
Это 16 кб блокировка, я тоже не могу пробить http на своем интернете. Может быть найдутся люди более разбирающиеся в вопросе, тренироваться можно на ресурсе http://gpu.me/v1/index2.json
CF пробивается пока что достаточно просто, а на некоторых провайдерах его вообще не блочат)
Да тоже самое все, как и с TLS. Надо подсовывать http req с теми же белыми хостами, что работают на TLS.
Только нет встроенной функции http_mod на подобии tls_mod, но http_req в блокноте написать - 2 строки или даже присвоить значение блобу в lua_init, используя \r\n. Или string.gsub на fake_default_http иану на беляк
http сейчас мало кому надо. в основном идет редирект на https, что вполне вписывается в 16 кб