В Tixati и BiglyBT можно задавать исходящие интерфейсы (в первом, к сожалению, по одному на IPv4 и IPv6, во втором можно несколько, но без разделения по protocol family).
Я могу попробовать это сбилдить на линукс, сишарп все таки
У моего провайдера нет IPv6, так что эту часть можно не обсуждать. Что касается клиента, то вроде как в uTorrent есть параметры net.bind_ip и net.outgoing_ip, чтобы привязать клиент к конкретному сетевому интерфейсу. Второй сетевухи, правда, нет, но надеюсь, получится второй IP поднять на компе и привязать uTorrent именно к нему. В любом случае, это всяко лучше, чем искать “плохие адреса”. Потому как VPN-сервисов в мире дохрена, я до конца жизни буду тогда искать и блокировать в файрволле IP’шники. Мне проще 120 руб. в месяц за еще один внешний IP начать платить, и чтобы голова у меня больше не болела на эту тему.
почему к конкретному айпи? можно и весь dht
не знаю правда нагрузит ли это проц на 100%, но это надо писать скрипты виндиверта.
раз есть желание решить вопрос, то можешь изучать))
речь шла о тестировании конкретного айпи
curl> блок, а потом уже можно и на весь dht распространить
так то zapret поддерживает filter=dht
tcp-syn (без ответа) уже триггерит блок, я полагаю любой трафик будет триггерить, скинь страту запрета которую хочешь проверить
ну какой нибудь белый фейк, просто когда отваливался hetzner по ip , то помогали фильтры по подсетям, читал такое
блок после первого пакета tcp-syn, еще до client hello, фейкать остаётся только tcp syn
я думал dht это udp
ладно я не силен в торрентах, не буду больше лезть)
quic запрос с белым sni который работает на оракле и клауде не помогает
Да, DHT-сеть использует UDP-протокол для отправки пакетов. Но что именно тут дурить? DHT ведь по сути сеть поверх сети, планетарного масштаба - буквально. Сиды и пиры, найденные через DHT, могут быть как в соседнем доме, так и на другой стороне земного шара. Плюс там нет доменных имен, чисто IP используются, это же прямое соединение между двумя ПК + какое-то количество пиров (инфа о них) передается просто в фоновом режиме, т.к. торрент-клиент старается поддерживать актуальность инфы о доступных и недоступных пирах. Это динамическая сеть, у которой нет четких границ. Куда слать фейки? Вообще по всем адресам? ОК, допустим. Но тогда мы гарантированно получим ситуацию, когда ближайший ТСПУ может быть обманут, но сработает более дальний ТСПУ. Это же не конкретный сайт, у которого есть конкретный хостинг и до которого можно рассчитать количество хопов, чтобы прописать их в TTL-параметре стратегии дурения - пиры могут быть где угодно.
Я, конечно, не эксперт по Запрету, но я не вижу способов как можно обойти подобное.
А откуда мы знаем, что это осмысленные действия? Больше похоже на коллизии хэшей.
Протокол DHT для цензурирования не слишком интересен, он имеет фиксированный формат и не шифрован (в основной (mainline) DHT; в Azureus и потомках свой протокол с обфускацией ещё с двухтысячных). Объём данных в типичной сессии тоже мизерный.
Если гадать, то диапазоны адресов хостингов и VPN-сервисов могли просто купить у компаний, предоставляющих такие данные (например, для соблюдения авторских прав в нужных странах), утащить какие-то старые публичные списки, дополнительно перебрать тестами и так далее. Но проверять каждый проходящий пакет на вхождение в миллион маленьких подсеточек сравнением адреса миллион раз не получится в масштабах магистральных каналов (да я в курсе, что провайдерские маршрутизаторы, которым нужно работать с полной глобальной таблицей BGP, буквально этим самым и занимаются, но там специфическое оборудование, спроектированное под эту задачу). Поэтому, вероятно, некоторое количество характерных адресов (например, серверов авторизации, к которым клиентские приложения популярных VPN-сервисов обращаются в начале сеанса, и прочих нехороших сервисов) было выделено в список, чтобы после появления подпадающих под него пакетов весь трафик с пользовательского адреса какое-то время проходил через затратные проверки на диапазоны адресов, протоколы, статистику трафика, и обрезку всего, что железка считает непонятным. Вероятно, этот список адресов (или набор правил) реализован как хэш-таблица, и, возможно, количество битов в хэше выбрано неправильно (или в случае составного хэша битов, зависимых от адреса, слишком мало), поэтому случайные соединения из-за совпадения хэша попадают в одну ячейку с заданным для фильтрации.
На месте Cloudflare я бы вставил всем пользователям на paywall-странички скрипт для соединения с некоторым количеством случайных портов на случайных IP-адресах. Если они маркировку браузера пользователя для отслеживания на всех своих сайтах называют проверкой безопасности, то и это пускай назовут проверкой доступности глобальной сети. Мечты, мечты.
Тоже настигла эта проблема.
Использую одновременно несколько торрент-клиентов. Один только под закрытые иностранные трекеры, другой все остальные. Если оставить работать только клиент с закрытыми, то пока блок не срабатывал. Возможно потому что на закрытых трекерах отключен DHT или разрешены не все VPN и Сидбоксы.
Может такое разделение кому-то поможет сократить количество блоков.
Как один из вариантов можно использовать Сидбокс. Там и скорость и место по вкусу можно подобрать, вопрос в цене. И минусы конечно, как уже выше предлагали вариант с VPS - контент не у вас на пк.
да никто и не предлалал качать на впс, предлагали арендовать впс для впн, сетевой интерфейс (с высокой метрикой чтобы весь инет трафик туда не шёл) которого можно выбрать в торрент клиенте
Да это и так понятно, что дхт ноды не являются целью, вопрос скорее в том, зачем глушить левые хостинги, не трогая при этом сам адрес “триггер”.
как минимум в случае 23.251.49.123 блочится и он сам, мгновенно, ни единого пакета не приходит
Сам адрес триггер во всех случаях тоже страдает. Это со стороны выглядит как небольшой рейнж IP адресов триггеров, на которые если полетит пакет, блокируюется гораздо более огромный рейнж и этого хостинга, и ещё может быть парочку соседних
у меня поменялась блокировка, как минимум хетзнера и ovh: раньше после триггера блочился весь трафик кроме icmp (даже tcp syn не проходили), щас же разрешен ssh и возможно есть какой-то белый список доменов на http/s
Проверил клиенты qBittorrent, uTorrent и Transmission, не один из них не блокирует исходящие DHT пакеты по черным спискам. Остаётся только блокировать на самом роутере. Выкладываю свой список ip адресов на 02.01.2026 В списке: все актуальные ip из этой темы + своё, примерно за месяц наблюдения. Принцип составления - сначала ловлю тригерящий ip, затем специальным скриптом отрабатываю всю его подсеть.
ipban.txt (40,1 КБ)
Я по итогу был вынужден разделить трафик торрент-клиента и весь остальной, https://rutracker.org/forum/viewtopic.php?p=88640273#88640273 - потому как понял, что ловить Wireshark’ом плохие IP очень муторный и долгий процесс. И по сути бесконечный.
del