Какие способы могут помочь при блокировке битторента? Дурение DPI с помощью условного запрета помогут? Прокси? Насколько я знаю много ВПН сервисов запрещают скачивать и раздавать какие либо торрент файлы. Можно использовать ТОР, но как по мне это слишком вредно для самой сети тора

Warp

i2p

Смотря как заблокируют.
От навальной блокировки DHT спасали udp фейки или tamper протокола

Торренты в I2P вроде “закрыты” в своей сети? Это будет иметь мало смысла, если мы говорим про основного потребителя торрентов с какого не будь рутрекера

DHT используется для trackerless раздач. У меня, например, он выключен ввиду отсутствия необходимости в нём.

вот поэтому нужно потихоньку уходить. у рутрекера нету контента, контент у нас, у юзеров. сделать зеркала торрентов в i2p не составит труда

К сожалению сейчас уже не то время. Большинства ведь даже и не знают зачем раздавать торренты после основной закачки. Поэтому может и действительно кто то перейдет на более “защищённые” методы передачи торрентов, а то и к P2P, но основная масса баранов побежит с радостью есть говно в ВК

советую включить и встать на раздачу популярной дистры
например del (удолено ибо таким образом можно сопоставить ip здешних юзеров со временим поста. но вы понели ;))

чтобы всегда dht ноды были в кэше. это имеет смысл иметь на “всякий случай” при чебурнете и интернет блекаутах

Да зеркала есть в и2п. даже рутрекер есть в и2п. Вопрос то в том, что рутрекер из клирнета не уйдёт. Они даже отдельно расширение для браузеров сделали, чтобы онли на рутрекер заходили все

i2p жутчайший тормоз
вместо 10 мб/с будете видеть в лучшем случае 20-30 кб/с
помню когда-то с постмана что-то пытался качать. 2 кб/с еле еле
а сайты грузятся по минуте страничка

Считаю скорость не особо важна если мы говорим про чебурнетовский сценарий с белыми списками. Главное любым способом добраться до информации которая запретила “партия”. Люди будут готовы неделями ждать закачку какого не будь зарубежного фильма, нежели читать советские газеты об очередных успехов по выращиванию пшеницы

Скорость зависит от пары туннелей, выбранных для конкретного соединения. Обычно торрент-клиенты создают по одному соединению к каждому пиру, т.е. скорость скачивания зависит от количества раздающих.

Скорость можно увеличить:

1. увеличивая количество раздающих
2. создавая несколько соединений к одному пиру (нужна модификация торрент-клиента + некоторым может не понравиться)
3. укорачивая длину туннелей (особенно: входящих при скачивании, исходящих при раздаче), тем самым меньше вероятнось “нарваться” на медленного участника туннеля (но может быть понижена анонимность)
4. увеличивая количество туннелей (но это полезно только при множестве разных соединений - пункты 1 или 2) (количеству туннелей есть предел)
5. заставляя i2p отправлять пакеты одного соединения по разным туннелям (нужна модификация i2p-роутера на стороне раздающих + это может быть нестабильно из-за различной стабильности разных туннелей)

Под соединением подразумевается одно потоковое соединение (tcp-like, streaming library, SAM session style=stream)

This post has been published from I2P.

в постмане в наше время неплохо. можно достичь ~1мб/с. да и даже если будет медленно, делов-то. i2p все равно у многих как демон 24/7, можно и на недельку оставить

Вот прямо сейчас работа yt-dlp поверх socks i2p

image909×78 27 KB

UPD:
туннели в 1 hop

inbound.length = 1
outbound.length = 1
inbound.quantity = 16
outbound.quantity = 16

Надеемся конечно на лучшее, но если вдруг резко поднимется популярность сетей типа i2p, разве скорость не станет выше, просто потому что стало больше пользователей?
Она вроде низкая, потому что технология интересна лишь паре тройке энтузиастов.

IMHO, тут будет сложнее.
Допустим, I2P резко станет популярным в РФ. Это будет значить, что большая часть роутеров в РФ будет за провайдерскими NAT, и среди них ещё много кто на мобильном интернете. То есть без возможности принимать входящие соединения на IPv4, и очень часто без поддержки IPv6 в принципе.
В итоге увеличится нагрузка на тех пиров, которые способны принимать входящие IPv4 соединения, следовательно понизится общая скорость сети, и, скорее всего, понизится значительно.

Впрочем, вроде бы в I2P предусмотрен какой-то механизм для hole punching, но я не знаю, насколько хорошо он работает в принципе и в условиях РФ в частности, и работает ли он в I2Pd, как в решении, которое, на мой взгляд, сейчас чаще всего рекомендуется к установке.
Если механизм hole punching действительно есть, и работает хорошо, то обозначенных проблем удастся избежать.

Hole punching есть давно Как I2P-роутер работает без выделенного IP-адреса. Магия прямого подключения двух абонентов за NAT-ом / Хабр
И он же используется для скрытия белого адреса роутера, при максимальной паранойе)

Хорошая статья, спасибо. Радует, что в I2Pd предусмотрено, не только в Java-варианте. При моих поисках эта статья не попадалась, попадались только страницы про Java-роутер. Но остались вопросы:

1. В случае с роутером за NAT, использующим hole punching, нормально ли через него проходит транзитный трафик, или в таком сценарии идут лишь пользовательские туннели / транзитный трафик есть, но крайне мало? Хотелось бы помогать здоровью сети хоть как-то.
2. В статье сказано:

Надо заметить, что трафик пользовательского приложения и транспортный протокол I2P – две независимые плоскости, т.е. фактически пользовательский TCP-трафик может передаваться через SSU.

Как конкретно это возможно реализовать?

С точки зрения роутеров транзитный трафик не отличается от пользовательского/сервисного. Даже трафик до сервиса с точки зрения роутера в общем-то транзитный.

Как это реализовано, вопрос скорее к разработчикам этого чуда. Но, с другой стороны, vless умеет делать UDP over TCP, aka UoT. Wireguard инкапсулирует любой трафик в зашифрованный udp. Почему это же не может делать i2pd?

Вот я совсем не разделяю вашу веру в i2p. Во-первых, если будет белый список протоколов, то i2p его не переживет. Во-вторых, i2p - сама по себе палево, причем даже без dpi, просто по открытым портам. В i2p был бы смысл, если бы она могла работать не поверх провайдерского IP, а мимо него. Где-нибудь на Мальте, где все друг у друга на головах сидят, это, наверное, вариант, но в РФ - вряд ли. И да, я тоже думаю, что большинству просто будет лень, проще пойти в ВК.

I2P - это сеть, пересылающая пакеты между destinations, внутри тоннелей. Тоннели проходят через участников (один за другим: A->B->C). Участники могут соединяться друг с другом через NTCP2 (обёртка вокруг реального TCP) или SSU2 (обёртка вокруг реального UDP). Как можно заметить, в I2P destinations - аналог реальных IP-адресов.

Пакеты - это по сути низкоуровневые датаграммы (аналогия: сырые IP-пакеты), поверх которых реализуется datagram или streaming (внутрисетевые аналоги UDP и TCP).

I2P (или по крайней мере i2pd) может также работать в меш-сети Yggdrasil, которую можно построить поверх реального интернета (в т.ч. tls и quic соединения; такие узлы действительно есть, даже публичные), или даже вне интернета посредством ethernet или wifi соединений.

В этом не будет особого смысла. После белых списков РКН перейдет к модерации самих российских платформ. Возможно добавят мониторинг “запрещенного контента” с помощью ИИ. Все таки я буду считать, что P2P связь и общая децентрализация должны стать трендами в это десятилетие, хотя возможно можно делать как те же туркмены и иранцы - максимально пытаться скрыть свою ВПСку, но и это тоже возможно не поможет если мы будем иметь сценарий ковровых бомбардировок иностранных хостеров

Если приплетается yggdrasil, то зачем в этой схеме i2p?
На тру обсуждалось уже - нужно включать интерфейс на трекерах чтоб раздавать адреса и все дела.
ygg интересная штука, но это тот же tls - а его заблочить не проблема если станет популярным

как раз когда блокировали dht была идея написать что-то вроде прокси, который представлял бы собой dht клиент и ноду на vps, но запросы бы слушал и как трекер. Итого, если скачивающий может узнать у такого трекера несколько пиров, которых тот спросит из dht - дальше сможет участвовать через peer exchange в trackerless раздаче. Это всё теория, да и хотел больше с образовательной целью, потыкать протокол, потому что звучит как что-то эгоистично вредное для сети в целом. Да и не лучше, чем публичный трекер через прокси, если раздача не начисто trackerless. Но руки пока так и не дошли, разрешаю украсть идею вдруг кому то покажется полезной

в идеале нужно писать новый торрент клиент который принимал бы фейковые пакеты, тогда Запрет точно справится. русские ip ркн вряд ли будет блочить, в этом вся суть чебурнета как бы, а сигнатуры может

Как минимум для повышения анонимности/конфиденциальности. Yggdrasil не ставит перед собой такой цели.

При коммуникации двух узлов в Yggdrasil между собой, некоторое количество посторонних узлов может узнать факт их коммуникации.

Более того, если была бы построена Yggdrasil-меш-сеть не через Интернет, думаю, можно было бы определить примерное местоположение узла, исходя из карты сети и знания местоположения других узлов - ведь существует карта, где показаны некоторые соединения между узлами сети.
(Но это не точно.)

Думаю, если надо, можно завернуть соединение в прокси, использующий любой известный способ обхода.

Можно написать плагин для BiglyBT. Там уже есть своя сеть дистрибуции Azure. (Но жаба-код ужаснейший).

Если будет белый список протоколов, то его не переживет не только i2p.
i2p не более палево, чем тот же торрент или shadowsocks.

если бы она могла работать не поверх провайдерского IP, а мимо него

Как вы хотите попасть в интернет мимо провайдера? Почтовые голуби?

Задача i2p:

• скрыть кто с кем взаимодействует
• скрыть реальное размещение сервиса (и его клиента тоже)

И поэтому (а также по иным причинам) лучше не качать торренты напрямую с российского ip и не использовать протоколы, которые выглядят как непонятное нечто. Ну и я все же считаю, что торренты с точки зрения РКН могут быть меньшим палевом, чем i2p.

Интернета не будет - будет чебурнет, и я туда вообще не хочу. Один из основных тезисов выше в том, что у юзеров есть контент. И вот если была бы какая-то связность… В 90-е, когда был dialup, “локалки на районе” существовали.

Вопрос в том, для кого не будет смысла Для вас и для меня, возможно. Но чтобы p2p работало, нужно некое не слишком маленькое множество юзеров, а вот в него я не верю.

Интернета не будет - будет чебурнет

А зачем, если патриотизм в стране зашкаливает? Куда ни зайди везде говорят какие хохлы плохие и ничего против войны. В Беларуси это ещё имеет смысл, там батьку многие не любят.

A что если i2p маскировать чем-то типа xtls-reality под трафик до vk например

i2p слоу. Лично я ко всем скачанным торрентам скриптом добавляю список публичных ретрекеров, а также ретрекеры в иггдрасиле.
скрипт для трансмиссии:

#!/bin/bash
test_tracker='retracker.local'
trackers=( `cat /var/lib/transmission-daemon/info/additional_trackers.lst` )
ids=(`transmission-remote --list | head -n -1 | tail -n +2  | grep '^ ' | awk '{ print $1 }' | tr -d '*'`)
for id in ${ids[@]} ; do
	if [ ! "`transmission-remote -t $id -it | grep $test_tracker`" ]; then
		echo "adding trackers for torrent with ID $id"
		for tracker in ${trackers[@]}; do
			transmission-remote --torrent "$id" -td "$tracker"
		done
	fi
	transmission-remote --torrent "$id" --start
done

additional_trackers.lst:

http://retracker.local/announce
udp://tracker.openbittorrent.com:6969
udp://tracker.opentrackr.org:1337/announce
http://re-tracker.ru:80/announce.php
http://retracker.ygg/announce
http://[21e:6565:9c87:a49d:dafa:92c1:b33f:f21]:1337/announce
http://[200:1e2f:e608:eb3a:2bf:1e62:87ba:e2f7]/announce
http://[316:c51a:62a3:8b9::5]/announce
http://[300:7232:2b0e:d6e9:216:3eff:fe34:ec44]:6969/announce

В яге даже бывает немножко траффика. Иногда.
Впрочем, если известен нормальный i2p ретрекер - могу добавить и его в список. В рамках эксперимента

Насколько мне известно, I2P не поддерживается в Transmission. Был какой-то форк, но он заброшен.

Некоторые торрент-клиенты для I2P:

• I2PSnark (bundled with Java I2P or standalone)
• qBittorent >=4.6 (или другой клиент, основанный на libtorrent-rasterbar) - необходима версия libtorrent >= 2, желательно >=2.0.10
• BiglyBT

Актуальный список открытых трекеров для I2P можно найти здесь (внутри сети):
http://wiki.i2p-projekt.i2p/wiki/index.php/Eepsite/Services#BitTorrent_open_trackers

Приведу также список здесь:

http://opentracker.dg2.i2p/a
http://opentracker.r4sas.i2p/a
http://opentracker.skank.i2p/a
http://opentracker.simp.i2p/a
http://tracker.eeptorrent.i2p/a

А трансмиссии не пофиг если i2p роутер работает в режиме транспрокси?
Чекнул, делает вид что работает. Как минимум один из 4 трекеров рапортовал что работает. Остальные правда сфейлились с ошибкой no ip (dest). Подозреваю, потому что при прозрачном проксировании ip2 хосту выдаётся один реальный ip адрес на все хосты. Но посмотрим
Как бы их не приложить с овер четырьмястами торрентами на раздаче

Если для этого используется SOCKS или HTTP прокси, то вряд ли пиры смогут инициировать соединения (будет примерно так же, как если вы за NAT в обычном интернете) - ведь через прокси можно только connnect, а не listen.

Тем более, если выдается 1 ip адрес на все хосты, то их различение, возможно, происходит с помощью HTTP-заголовка Host, которого не будет при соединении с пирами, поскольку Bittorrent не HTTP.

Так пиры и не должны качать через i2p ИМХО.
Пиры должны зайти по i2p на ретрекер и получить список клирнет пиров(что в теории сейчас и происходит. Трансмиссия не знает ничего про мой псевдохост в i2p сети при транспрокси схеме)
Если битторент траффик пойдёт через i2p сеть - она к чёрту ляжет
З.Ы. Вообще на самом деле супер любопытный вопрос конечно, что именно сейчас летит в качестве ip адреса пира и поддерживают ли i2p ретрекеры обычный ipv4 адрес в качестве адреса хоста вместо b64 псевдоадреса. И готовы ли торрент клиенты к получению ipv4 пира от i2p трекера. Возможно, ошибка no ip (dest) как раз и говорит об этом.

Нет, пиры должны соединяться через I2P, именно так и задумано:

Cross-Network Prevention

To preserve anonymity, I2P bittorrent clients generally do not support non-I2P announces or peer connections. I2P HTTP outproxies often block announces. There are no known SOCKS outproxies supporting bittorrent traffic.

To prevent usage by non-I2P clients via an HTTP inproxy, I2P trackers often block accesses or announces that contain an X-Forwarded-For HTTP header. Trackers should reject standard network announces with IPv4 or IPv6 IPs, and not deliver them in responses.

(source: http://i2p-projekt.i2p/en/docs/applications/bittorrent / Bittorrent over I2P - I2P)

Хотя, насколько often I2P HTTP outproxies block announces, неизвестно. Может, какие-то и не блокируют. (Но тут другой вопрос - примет ли трекер с IP-адреса 1.2.3.4 (outproxy) анонс о том, что раздача идет с IP 5.6.7.8, или не поверит и отбросит).

Ну и в теории можно какой-то свой сервер создать, который по I2P будет принимать анонсы клирнет-пиров. Скорее всего, даже никакой кастомный софт писать не надо будет, просто завернуть известный трекер в server-туннель. Тогда даже никакая поддержка от торрент-клиента не нужна (разве что только SOCKS или HTTP прокси, но и без этого можно обойтись).

Не, тот промежуточный ip никуда не идёт. Схема такая. На роутере есть статическая dns запись, которая резолвит все i2p хосты в условный 10.1.2.3
Дальше есть dst-nat правило, делающее редирект всему траффику на хост 10.1.2.3 с эни порт на 8080, где на роутере живёт http прокси. А у него в пэрэнт прокси уже прописан i2pd роутер в режиме транспрокси. В итоге клиенты нативно работают с i2p хостами через старый добрый tcp ip стэк. Наружу же до i2p ретрекера траффик идёт с i2p роутера и его b64 псевдоадреса. И вот дальше я не до конца в курсе, как работает анонсирование. Если на ретрекер улетает публичный ipv4 адрес, на котором пробит порт до трансмиссии - всё в шоколаде, всё будет работать(в теории). А вот если таки b64 адрес роутера - то всё фигня, давай по новой. Пиры просто не смогут подключиться. Наверное, можно прикрутить какой-нибудь транспорт или плагин к i2p роутеру, но как я уже сказал, мне совершенно не нравится концепция , когда битторент траффик гуляет поверх i2p - он тупо забьёт канал, а любая актуальная раздача на условных 100-200кбит(что является на текущий момент реальной пропускной способностью i2p сети) будет качаться примерно вечность.

Клиент отправляет свой IP-адрес трекеру при анонсировании. Тот адрес, который знает.

Клиент в данном случае ничего не знает про I2P, просто отправляет HTTP-запрос со своим IP-адресом. Соответственно, что отправил клиент, то и видит трекер. Destinations (b64) здесь нигде не присутствуют.

Но если так же попробовать с in-i2p трекерами (dg2, skank, r4sas, …), то они по идее должны такие запросы игнорировать, потому что предназначены для работы чисто внутри I2P. Так что в таком случае они не подойдут. (Но могут быть и такие, которые принимают - это надо проверять каждый).

Можно в личку, что скачать и откуда?

У меня уже неделю скорость торрентов рутрекера не превышает 200-500 кб/сек, даже на раздачах с сотнями сидов. Написано, что bt и DHT работают, но в DHT всегда или 0 сидов, или низкое кол-во, вроде 1-2. Только после большого количества кликов на “Force reannounce to all trackers” в qBittorrent в строке DHT появляются сиды, а с ними и скорость. Однако это работает не со всеми раздачами. Как это можно пофиксить? Это провайдер пытается так “резать” скорость? ТТК Сибирь, если что.

Попробуйте порт поставить 1024

такого не должно быть. трекеры вообще нужно вырезать для чистого dht. в магнет ссылках просто выреж наименования трекеров

магнеты опасны тем что действительно можно скоррелировать их (iknowwhatyoudownload через dht это видит). поэтому я не буду постить магнеты, даже если они легальные линукс дистрибутивы. я не хочу чтобы юзеров этого форума (которые сидят с впн) выследили реальный ip из-за такой чудовещной оплошности

Метод syndata в zapret. Создавался именно для этого.

Судя по всему, r4sas таки работает таким макаром, по крайней мере коннект к нему проходит, и в статистике даже got 16 peers. А вот остальные в списке - болт

В Tixati 3.32 добавили поддержку I2P.

В чем Tixati отличается от основной массы торрент клиентов? Кроме разве что I2P которые практически недавно добавили

Поддержкой торрентов с гигантским количеством сегментов, UDP прокси-релеев, возможности указать разные прокси для трекеров и пиров, политик фильтации трекеров и сетей пиров, возможности настроить разное поведение DHT для трекерных и безтрекерных раздач, опции проверки хэшей по завершению скачивания (можно сразу определить бэд секторы на умирающем накопителе). Из недостатков — нельзя пропатчить под свои нужды, отказ разработчика от поддержки IPv6 прокси, нельзя как в BiglyBT указать несколько используемых сетевых интерфейсов (только по одному IPv4 и IPv6), даунгрейд отображения диалогового окна списка торрентов при добавлении новой раздачи (нельзя отсортировать по дате создания, до какого-то обновления можно было), однопоточность.

Последовательное скачивание, богатые приоритеты файлов, больше возможностей по читерству на приватных трекерах (можно удалить трекер, вставить сохранённый список пиров), подробные логи соединений с пирами, заметки.

Это есть в qBittorrent и BiglyBT, например.

Нет.

Звучит очень даже неплохо. Правда интерфейс у тихати крайне неприветливый к новичкам. Есть ли гайды на настройку этого торрент клиента?

Не знаю, начнёт работать сразу из коробки. Можно разобратся в большинстве опциях тыкая на все кнопки подряд. Если качаете на HDD то рекомендую поменять настройку Transfers → Files → File allocation c Sparse на Fast Allocate для избежания фрагментации файлов (если вам важна скорость последовательного чтения или стоит дефрагментация по расписанию). Ещё можете поставить там же галку Redundant hash-check on completion: Transfers, тогда сразу узнаете о проблеме умирающего накопителя.