можно попробовать автоматизировать скриптом PS + chromedriver, но конечно это будет в разы медленней, по сути просто скриптом будут открываться сайты и собираться информация.
у меня в браузере не резет а зависание. возможно tls fingerprint влияет, можно сделать mitm через xray c utls chrome
У меня идея изначально была такая, насобирать айпишников на которые ломится мой кубитторрент, за те периоды когда хетзнер не работает с разбросом в 10 минут, с этой задачей я как нибудь уж справлюсь) а вот дальше по идее создать какой нибудь скриптик, которому кормишь лист этих айпишников, а он посылает на них нужный запрос и проверяет после этого хетзнер. Начал писать на шарпе (на чом уж умею извинитие) с помощью чата жпт подобную штуку, споткнулся сразу же, когда у меня в браузере написанно ресет, а скрпит мой считает что всё окей) взял курл, а курл тоже страничку загружает. А бразузер ресет пишет. Вот чёта не понимаю магия какая то, заголовки ли, кеш какой то или как так получается вообще
@0ka А вот у меня именно резет после скрипта, на 10 минуток
ну у меня получилось через xray mitm, utls даже не нужен чтобы блок был, но на всякий случай оставил его
конфиг: https://pastebin.com/raw/JWNSzNpy
тест через
curl -vk -x socks5h://127.0.0.1:10801 https://7-zip.org
или
curl -vk --connect-to ::127.0.0.1:4431 https://7-zip.org
для детекта блока можно добавить “-m 5” чтобы curl выходил с ошибкой после 5 секунд ожидания
если нужно что-то другое а не 7-zip.org то нужно сменить домен и айпи в конфиге
как вариант
Спойлер
о как, спасибо, нашёл форк более активный и под винду есть сборка GitHub - lexiforest/curl-impersonate: An active fork of curl-impersonate with more versions and build targets. A series of patches that make curl requests look like Chrome, Firefox and Safari.
переделал один свой скриптик под этот curl за место хромдрайвера
@0ka @the-d-kid а при добавлении в zapret заблоченые таким образом сайты открываются или нет?
через него (без доп параметров) у меня нет доступа к 7-zip.org как и через хром, отлично пойдёт для проверки.
P.S. размер его client hello всего на 200байт больше чем стоковый от curl, оба помещаются в 1 пакет
--dpi-desync=fake --dpi-desync-ttl=6 --dpi-desync-fake-tls=0x00000000 помогает обойти блок, google_hello.bin вместо 0x00000000 не работает, подключение со sni otus.ru или stackoverflow.com без запрета на айпи хетзнера тоже не работает (зависает после client hello)
Тогда я совсем не вижу проблемы. Только так и не понял с какой целью это было сделано. Обкат системы умной фильтрации, которая обрубает конкретному мутному абоненту инет? (частично или полностью)
сейчас 100500 разных блокировок
причем провайдер // ТСПУ (регионы разные.) // магистральные провайдеры
и там целый зоопарк
IP / CIDR // SNI // TLS1.3 вообще / или конкретные вроде TLS_AES_128_GCM_SHA256 / ech // googlevideo // http3/quic // DoH/DoT // DHT
причем для одного “ресурса” могут сработать сразу несколько
причём чтобы не офтопить часто “сопутствующий” ущерб как когда то в “блокировкой” телеграма
CDN77 == tor? и не только snowflake
DHT == разный софт для “обхода” на основе p2p
а нередко просто “за компанию” ибо хостеров не так и много. больше всего конечно Cloudflare достается ![]()
складывается у меня ощущение, что либо я какой то особенный, либо на форуме какая то мешанина из непонимания. Здесь я писал о триггере на блокировку хетзнера => Блокировка OVH после отправки UDP-пакетов DHT-пирам - #13 by the-d-kid
Продолжая наблюдения (с 3-4 провайдеров), и следя за форумом хочу поделиться своим вердиктом:
На моих провайдерах блокировки Scaleway, OVH, GCORE - связанны с этим самым триггером, однако VULTR, Akamai, DigitalOcean у меня работают даже при сработавшем триггере. Вот на каких сайтах проверял и какие у меня результаты при сработавшем триггере:
DigitalOcean:
178.62.84.203 www.linuxserver.io
134.122.96.191 www.ultraviewer.net
Akamai:
2.16.154.192 www.estadao.com.br
VULTR:
65.20.84.80 www.zhangtory.com
185.92.220.233 www.euk-info.de
Scaleway:
51.158.181.225 crystalcreekhackneys.com
51.158.176.124 nattomaki.social
OVH:
51.195.68.162 www.rarlab.com
94.23.3.229 www.cenest.net
137.74.1.182 platinum.edu.pl
GCORE:
92.223.24.117 www.wargaming.net
92.223.13.66 worldofwarships.com
На мобильных операторах не проверяю и не вижу в этом никакого смысла, так как на мобильных операторах все сидят за глубоким натом, я никак не могу проконтролировать не срабатывает ли триггер на IP адрес за которым я сижу на мобильных операторах из за других клиентов, более того у меня лично нет представления сколько абонентов сидит за одним IP адресом на мобильных операторах, если окажется что там счёт в сотни или даже тысячи абонентов - то постоянная блокировка хостеров не удивительна ибо сто процентов один из абонентов сидит и активирует триггер каким нибудь торрент клиентом, а ведь триггер начинает работать именно на внешний адрес за которым сидит клиент.
И кстати один из способов попробовать перестать активировать триггер торрент клиентом - выставить в настройках протоколов по которым работает торрент клиент только протокол µTP, абсурд, но при выставлении TCP only включается почему то BT протокол который самый что ни на есть UDP, а как мы помним из предыдущих наблюдений именно UDP пакеты триггерят блокировку
Подтверждаю, у меня аналогичное поведение. И разумеется Hetzner (замечу, что wetdry.world остается доступен) тоже после триггера блокируется.
Ниже несколько вариантов предложили, как проводить проверку. Что-нибудь удалось в итоге?
Что именно смущает? Кроме сообщений от @Noel77750 вроде бы всё по теме.
да, у меня так же, и 2ip.ru тоже работает при сработавшем триггере не смотря на то что он на хетзнере, всё остальное ложится. про эти два сайта писал в своём сообщении в топике про хетзнер)
к сожалению пока руки не доходят реализовать, xray proxy с настройками от @0ka (за что ему спасибо) хорошо работает для проверки, но до сбора айпишников и реализации скрипта пока руки не дошли увы
смущает то, что люди не понимают почему некоторые сайты не работают. Смущает то, что вероятнее всего, никто не блокировал хостинги на некоторых провайдерах, в частости все мобильные провайдеры, а просто на просто действует постоянная блокировка для большинства IP адресов за NATом, так как какие то клиенты постоянно её триггерят. т.е. проблема то не в том что на мобильных операторах что то заблокировали, а в этом самом триггере, который есть вообще то везде, но ощущается на мобильных операторах в большей мере из-за НАТа, за которым все сидят. По крайней мере у меня такая теория, я не настаиваю на правоте, как минимум для того что бы её доказать нужно каким то образом получить выделенный IP адрес от тех же мобильных провайдеров, и в течении 10 минут не триггерить блокировку, после чего запускать проверку. Не уверен есть ли вообще услуга выделенных IP хоть у кого то из операторов мобильной связи
Xray не нужен, ниже в спойлере скидывали ссылку на curl impersonate для винды. ну а вообще как ты это проверять собираешься я не представляю, срабатывание блока может быть не мгновенное, потом нужно ждать 10 минут для снятия, это же пипец гемор.
у меня на домашнем инете твой триггер перестал работать, а на моб мегафоне теперь блок OVH постоянный (а раньше блочился после триггера).
Опять же, откуда ты знаешь на мобильном инете что кто то вместо тебя с твоего внешнего src ip не триггерит блокировку?)
По поводу домашнего интересно
По поводу выявления полного списка айпишников для триггера - блокировка довольно быстрая, на самом деле (лично у меня, вот прям секунд 5, не больше), надо всего то записывать на какие ip обращался торрент клиент, с временем, одновременно с этим проверять блокировку, каждые 10-30 секунд, собрать этих данных за дня три-четыре, составить список адресов на которые обращался торрент клиент +/- минута от времени сработки блокировки, после этого на эти адреса посылать пакет который триггерит блокировку и через 10 секунд проверять сработала блокировка или нет, автоматизировать имхо не прям элементарно конечно, но и не очень сложно
Но пока что я только на словах такой умный, да и знать бы мне что проделанная работа будет не зря для меня хотя бы в течении полугода, а то как заморочусь а в итоге откатят этот бред
Проверил триггер еще на ряде провайдеров. Итого: 1 федеральный Дом.ру, 1 крупный региональный, 1 небольшой “местный” и 2 провайдера для юриков.
Триггер не срабатывает только на одном провайдере для юриков. На остальных 4 срабатывает, но диапазоны блокировок немного отличаются. Самое существенное - на провайдере для юриков, где срабатывает триггер, блокируется также Cloudflare, но только часть диапазонов.
На этом же прове для юриков вдобавок к wetdry.world не блокируется archlinux.org. Но другие сайты на Hetzner блокируются.
Также отмечу, что на местном провайдере доступен ютуб на полной скорости, и вообще ряд блокировок отсутствует.
Ясно. Просто я изначально прочитал “на форуме” как “в этой ветке форума”. Касательно ntc.party в целом:
Summary
О каком понимании может идти речь, когда отсутствуют “протоколы проверки”? Инструкции с последовательностью действий для определения источника типовых проблем.
К примеру, то и дело слышны заявления вроде “vless заблокировали”. В то время, когда по факту там блокировка всего https до хоста, а то и вообще авария на магистрали.
Тут же случай куда сложнее, поэтому мешанина и непонимание вполне закономерно.
Всем здравствуйте
Что-то в итоге удалось, правда результат предсказуем, но об этом чуть позже
Написал программу, сейчас она имеет три функции, 1-ая - каждые 10 секунд проверять загрузку сайта 7-zip, логгировать загружается он или нет. 2-ая - брать из txt список ip/port и отправлять udp паект на каждый ip из списка после чего ждать 5 секунд и пытаться загрузить 7-zip, результат пишет в лог и консоль. 3-я - аналогична второй функции но для TCP
Некоторые подробности:
- для корректной проверки триггера я запускаю всё таки xray c конфигом от 0ka, и пишу в hosts 127.0.0.1 7-zip.org (иначе запросы на 7-zip видимо настолько маленькие, что они проходят при том что из браузера сайт не загружается)
- TCP проверка требует установки соединения, за саму попытку установить соединение триггер не срабатывает (но как оказалось дальше это не так уж и нужно)
Результаты наблюдений:
Я проводил наблюдение в сети, где уже заворачиваются подсети 134.195.196.0/22, 51.159.0.0/16, 62.210.0.0/17. Далее запускал свою программу в первом режиме и ждал сработки триггера, при этом собирал все отправленные qbittorrent-ом пакеты программой ProcessMonitor. В ProcessMonitor устанавливал два фильтра, первый на имя процесса, второй на исключение оторбражения событий у которых в Path есть 127.0.0.1. Нюанс в том, что к сожалению нельзя оставить даже на день (не то что на неделю) это всё безобразие что бы собрать как можно больше данных, так как ProcessMonitor просто крашится через 2 часа от слишком долгого захвата. Как решить эту проблему пока не придумал, но даже рамки в 2 часа хватило что бы поймать пакеты от торрент клиента, в момент когда сработал триггер (что хорошо позволяет понять моя программа при работе в первом режиме с точностью в +/- 10 секунд. После долгожданно пойманого момента когда триггер сработал, я остановил торрент, выгрузил в CSV захват из ProcessMonitor, notepad++ом вычистил запросы на локальные ip, и провёл махинации по разделению пакетов на TCP и UDP (TCP у меня оказалось в 10 раз больше), нехитрыми махинациями оставил только связки ip:port на каждой строке в каждом файле (под TCP и UDP) и запускал в соотвествующих режимах свою програмку. UPD проверку прошли все адреса, а вот TCP проверялось сильно дольше, и на 7-ом часу проверки моя программа смогла стриггерить триггер, успешно поняла это и доложила о виновнике торжества. им оказался 151.115.97.151:42472. И о боже, какая неожиданность, IP адрес пренадлежит Scaleway) Мда уж, чё сказать. Далее ради интереса попробовал туда же отправить UDP запрос, и о чудо, UPD запрос тоже стриггерил блокировку, не смотря на то что торрент клиент стриггерил её TCP запросом. Т.е. видимо протокол не так уж и важен, можно все адреса всегда проверять более быстрой UDP проверкой.
По поводу скорости срабатывания триггера, уж не знаю у кого как, но после вычисления кто же был виновником торжества, и при поиске его в захвате, видим следующее. Что писала моя программа:
15.08.2025 xx:32:45: всё збс вроде
15.08.2025 xx:32:55: всё збс вроде
15.08.2025 xx:33:05: всё збс вроде
15.08.2025 xx:33:25: Таймаут запроса.
15.08.2025 xx:33:45: Таймаут запроса.
Как видим проверка каждые 10 секунд, при этом уже в 33 минуты 15 секунд пакет не отправился, + 10 секунд таймаута, после чего сообщение о таймауте. Где же у нас был пакет на указанный адрес в захвате?
"xx:33:15,0804113","qbittorrent.exe","23056","TCP Connect","192.168.0.2:51906 -> 151.115.97.151:42472","SUCCESS","Length: 0, mss: 1460, sackopt: 1, tsopt: 0, wsopt: 1, rcvwin: 65535, rcvwinscale: 8"
В те же 15 секунд. То есть я либо где то ошибся, либо триггер быстрее, чем можно себе представить.
Прогу свою могу как то выложить, правда не знаю как, на гит или просто в архиве на форум. Могу хоть с сурсами, но писал на скорую руку, не серчайте. Возможно её даже можно доработать что бы она не требовала xray, но мне не хотелось с этим заморачиваться
Как то так.
Про curl impersonate пропустил сообщения или он у тебя не работает? Время в твоем тексте и логах не совпадают. Вообще я думал ты хотел весь ipv4 просканить (в реале выйдет только по одному айпи из каждой подсети всех asn), я бы просканил если бы у меня работал триггер
Прошу прощеня про игнор curl impersonate, я не стал пробовать потому что у меня по сути проблема то была не в том, что curl не работает, у меня проверка в моей проге идёт не через курл, а через какую то наверное дефолтную библиотеку (я дурачёк и проверку сайта я навайбкодил так что особо не знаю чё там происходит). И просто дефолтная библиотека ведёт себя как дефлтный курл, и когда я xray-ем могу пофиксить и дефолтный курл и получить желаемое поведение от дефолтной библиотеки меня устраивает больше, чем когда мне надо какой то кастом курл вызывать из кода и ещё перехватывать и обрабатывать его вывод как то.
Время щас поправлю, я дурачёк и поменял его для успокоения шизы, да только не везде X)
Иедя про один айпишник из каждого asn интересная, но перед этим надо бы убедиться что триггер висит на asn а не конерктные подсети, ну и вопрос сколько айпишников получится если взять по одному на каждую asn
Если там хотя бы не больше 10к айпишников и если кто то сформирует такой список то могу попробовать запустить (правда жалко сайт 7-zip’а, но надеюсь они меня простят за такие фокусы)
