Блокировка OVH после отправки UDP-пакетов DHT-пирам

можно попробовать автоматизировать скриптом 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 достается :wink:

складывается у меня ощущение, что либо я какой то особенный, либо на форуме какая то мешанина из непонимания. Здесь я писал о триггере на блокировку хетзнера => Блокировка OVH после отправки UDP-пакетов DHT-пирам - #13 by the-d-kid
Продолжая наблюдения (с 3-4 провайдеров), и следя за форумом хочу поделиться своим вердиктом:
На моих провайдерах блокировки Scaleway, OVH, GCORE - связанны с этим самым триггером, однако VULTR, Akamai, DigitalOcean у меня работают даже при сработавшем триггере. Вот на каких сайтах проверял и какие у меня результаты при сработавшем триггере:
DigitalOcean:
:white_check_mark: 178.62.84.203 www.linuxserver.io
:white_check_mark: 134.122.96.191 www.ultraviewer.net

Akamai:
:white_check_mark: 2.16.154.192 www.estadao.com.br

VULTR:
:white_check_mark: 65.20.84.80 www.zhangtory.com
:white_check_mark: 185.92.220.233 www.euk-info.de

Scaleway:
:cross_mark: 51.158.181.225 crystalcreekhackneys.com
:cross_mark: 51.158.176.124 nattomaki.social

OVH:
:cross_mark: 51.195.68.162 www.rarlab.com
:cross_mark: 94.23.3.229 www.cenest.net
:cross_mark: 137.74.1.182 platinum.edu.pl

GCORE:
:cross_mark: 92.223.24.117 www.wargaming.net
:cross_mark: 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
Некоторые подробности:

  1. для корректной проверки триггера я запускаю всё таки xray c конфигом от 0ka, и пишу в hosts 127.0.0.1 7-zip.org (иначе запросы на 7-zip видимо настолько маленькие, что они проходят при том что из браузера сайт не загружается)
  2. 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’а, но надеюсь они меня простят за такие фокусы)