bundle сочетает в себе z1 и z2. чтобы не поддерживать 2 сборки проще так сделать
Товарищи, вот сейчас вопрос - datacamp limited ркн весь блочит? Или есть какие-то ip в белом списке?
Вроде как на всех IP 16кб блок. По крайней мере, за почти 2 месяца активных блокировок, ни одного их IP который не блочится, выяснить не смог
Я собираю. Для OpenWRT/Entware(Keenetic/MerlinWRT)/VPS и т.п. В меру своих знаний, сил, времени)
Стратегии не мои, на это меня не хватит уже)
Меню скрипта-сборки
кто по wireshak может вывод сделать?
dsst.online.pcapng (126,7 КБ)
1- чебурнильские дела
2- сам сайт именно меня не любит? (пинг есть. есть даже nc -z на 443 а данных нету)
практически полное отсутствие ответов от сайта напрягает
в захвате сначала без запрета потом с ним в 2х вариантах где всё работает кроме сайта сабжа
Похоже на чебурильские.
вероятно чебурение хостинга/CDN, тк тот же SNI на левые IP не вызывает блока, любые SNI на оригинальный IP вызывают, а вне России коннектит без проблем.
dsst задели, баня хостинг. вероятен белый список по неизвестным SNI
Worldstream is a Dutch cloud infrastructure provider offering dedicated servers, cloud hosting, and a massive, low-utilization global network (10Tbit/s+) with built-in DDoS protection, focusing on transparent pricing and digital resilience for businesses needing scalable, high-bandwidth solutions, especially for AI/ML and edge computing.
спс
чебурненье видимо не всей эрэфии
постфактум догадался задействовать другого прова
там минимум на 80 его не блочат вовсе. но 443 уже да
но что неприятно удивило что блокчек на 80 suspicious redirection 301 to : https://dsst.online:443/ за успех несчитает
не понял почему?
причём как думаю это точечная блокировка именно этого хоста с этим ip
пару недель назад этот балансер был по адресу csst.online и так же здох а ожил когда на dsst.online переделали - но мудачьё заметило
при этом это именно балансер и редиректит на другое - а это другое не трогали ещё
Не предусмотрено выпарсивание порта, он считает домен как “dsst:443”, что не равно исходному домену
На соседнем IP в пределах /24 пробовал - тоже самое
столкнулся с такой же проблемой сегодня, перебрал полный цикл blockcheck и ни одна стратегия не сработала для rr4---sn-8ph2xajvh-n8vs.googlevideo.com. кто-то знает как это обойти?
Такие хосты блочат
Либо если данный хост имеет несколько Ip, то через hosts привязывают к рабочему (доступному) ip
И после этого начинают искать стратегию
В чём может быть причина того, что один и тот же sni приводит к различному результату на разных айпи одного и того же хостинга?
Проблема в стратегии или же это как-то хитроумно настраивают тспу чтобы “вот для этого айпи работали вот эти sni, а для другого айпи другие”?
curl.exe https://cdn.myanimelist.net/images/anime/1783/106843l.jpg -o NUL --progress-bar -r 0-35000 --max-time 5 --connect-to ::95.101.171.168
############################################################################ 100.0%
curl.exe https://cdn.myanimelist.net/images/anime/1783/106843l.jpg -o NUL --progress-bar -r 0-35000 --max-time 5 --connect-to ::95.101.137.102
############################################################################ 100.0%
curl.exe https://cdn.myanimelist.net/images/anime/1783/106843l.jpg -o NUL --progress-bar -r 0-35000 --max-time 5 --connect-to ::95.101.78.51
################################## 45.2%
curl: (28) Operation timed out after 5003 milliseconds with 15807 out of 35001 bytes received
curl.exe https://cdn.myanimelist.net/images/anime/1783/106843l.jpg -o NUL --progress-bar -r 0-35000 --max-time 5 --connect-to ::95.101.35.66
################################## 45.2%
curl: (28) Operation timed out after 5010 milliseconds with 15807 out of 35001 bytes received
давно замечено, что они на разные хостинги ставят разные правила
идентифицируют по IP. а как еще ?
и замечал, что на CF некоторые диапазоны подпадают под спец фильтр, а другие -нет
отнес бы к несовершенству списков ip хостингов
Тут получилось так: ютуб стал через некоторое время использовать другие домены.
Или пробовать 2 штуки.
Попробуй почисти кэш браузера для youtube.com , чтобы обновились скрипты и возможно по-другому будет работать.
Тоже пару дней назад перестали пробиваться некоторые домены googlevideo.com, но иногда они работают нормально, а иногда нет. Блокчек накидал возможных стратегий на проблемные домены, но ни одна не дала результата - все еще рандом.
Тут даже не разные хостинги, а соседние диапазоны одного хостинга.
Сегодня волею рандома dns-ных богов выдался айпи 2.21.89.96 для которого не то что не нашлось sni, но даже не приходят ~16кб.
В целом какой-то проблемный сайт на айпи от Akamai. Если использовать вместо фейка сековл-паттерн, то есть рандомные задержки в несколько секунд перед началом загрузки данных.
Подозрительно похоже на выдачу доменам гугла айпи (142.251.42.142 142.250.71.206 142.250.206.206 142.250.70.238 142.251.42.206 142.250.71.78 142.250.207.46 142.250.197.46 142.250.207.110) на которых тоже либо ошибка, либо загрузка начинается с задержкой в несколько минут.
Нашёл три возможных решения проблемы:
- самый очевидный - прописать в hosts айпи для которого работает нужный sni
- “умный в гору не пойдёт, умный гору обойдёт” - помимо Akamai сайт также использует другие хостинги на которые пока что не распространяется 16кб блокировка
Liquid Intelligent Technologies41.175.223.8,41.175.223.16
Embratel200.248.226.10,200.248.226.11,200.248.226.17,200.248.226.18
Zong111.119.184.145,111.119.184.152,121.91.41.178,121.91.41.241
Eir Broadband194.125.178.145,194.125.178.162,194.125.178.202,194.125.178.203
Tata Communications64.7.118.136,64.7.118.144 - слегка извращённый - почему-то поддомену
mxj.myanimelist.netвыдаются айпи хостинга Amazon CloudFront. Поэтому можно раскомментировать cloaking_rules в dnscrypt и добавить правила
=myanimelist.net mxj.myanimelist.net
www.myanimelist.net mxj.myanimelist.net
cdn.myanimelist.net mxj.myanimelist.net
image.myanimelist.net mxj.myanimelist.net
Символ = нужен чтобы не получился замкнутый цикл *.myanimelist.net ← mxj.myanimelist.net ← *.myanimelist.net
Потестил несколько айпи Amazon CloudFront 3.162.103.13 18.238.49.41 99.84.118.42 108.157.142.79 143.204.194.27 и вроде бы пока что нет проблем со sni и сековл-паттерн.
Случайно обнаружил, что, похоже, --dpi-desync-fake-tls-mod=sni= ограничен 126 символами, а не стандартным для доменных имён ограничением в 256.
Конструкция рандом.+sni длиной в 126 символов блокировку снимает, но при рандом.+sni с большей длиной не работает, как будто происходит отбрасывание символов после 126.
В подтверждение этому является успешной комбинация рандом.+sni (=126) + любое дополнительное количество рандомных символов.
Очень маловероятно, что длинные sni подходящие для стратегий существуют, но всё же.
struct fake_tls_mod
{
char sni[128];
uint32_t mod;
};
Так и есть. Предположить не мог, что кто-то захочет больший размер.
Пробивается благодаря длинному SNI ? Не понял описание
Нет, просто решил узнать примет ли без проблем тспу рабочий sni если у него будет максимально возможный поддомен увеличивающий общую длину до максимально возможных 256 символов.
Как оказалось принимает.
И, наоборот, в случае sni который работает если у него указан рандомный поддомен random.site.com и не работает сам по себе site.com, можно поскупиться и указать только точку --dpi-desync-fake-tls-mod=sni=.site.com.
потыкал ради интереса: после любого TLS пакета с любым SNI отваливается соединение. обычное TCP рукопожатие работает нормально. не ясно, зачем такой фильтр нужен именно на этом адресе