Pull to refresh

Comments 108

Присутствие pornolab.net в топе радует… :)
А разве модификация трафика провайдером не нарушает каких нибудь законов или вроде того?
А что вы называете модификацией? Замена ARP-адреса и уменьшение значения TTL в ip-пакетах на маршрутизаторах тоже под модификацию трафика подпадает. ;)
Это не пользовательский трафик, это служебные заголовки, которые совершенно не волнуют пользователя.
Тоже самое как если я заказываю такси, то мне все равно на чем оно едет — на бензине или солярке. Так и тут ARP-адрес — та «солярка», с помощью которой передается полезное содержимое.
Автоматическое изменение данных, запрашиваемых пользователем, не очень то укладывается в «нейтралитет».
В таком случае вы неправильно понимаете смысл термина.
Данное изменение тождественно указанию ip-адреса для DNS-имени retracker.local, не ухудшает трафикообмена пользователя и поддаётся контролю со стороны пользователя.
Если коротко обобщить, задача провайдера — передать трафик из точки A в точку B. Именно это подразумевается под «предоставлением доступа в Интернет».

Кстати, вполне возможно что этим нарушается какой либо пункт в договоре предоставления услуг, заключаемом абонентами — если им в каком либо виде гарантирована передача их трафика без изменений.

В общем, моё мнение — как технический трюк забавно, но в остальном — сомнительно.
Я понимаю, но увы, действительность далека от принципов теоретиков: цисковские роутеры не обрабатывают icmp-пакеты с тем же приоритетом, что и пропускаемые, мы контролируем одновременное количество SMTP-коннектов, а ещё закрываем порты NetBIOS и DHCP и блокируем за вирусную активность.
Имхо это немного из другой оперы. Обеспечение жизнедеятельности сети это одно, навязывание непрошенных услуг — немного другое. Разве что у вас очень серьезные проблемы из-за чудовищных количеств исходящего p2p-траффика.
Вы очень упрямы. Ещё раз прочитайте этот комментарий и подумайте над тем, каким образом замена одного DNS-имени на другое, оба из которых разрешаются в один ip, является навязыванием услуги.
Да, тогда это не навязывание услуги. Но имхо всё равно слишком странное решение для не очень то серьёзной проблемы.
Скользкий вопрос. Data discrimination не наблюдается, вы согласны?
Операция замены в файлах имени retracker.local на retracker.smarthome.spb.ru равнозначна DNS -ответу retracker.local CNAME retracker.smarthome.spb.ru.
А я не говорю про data discrimination. Представьте что Вы парсите html-файлы пользователя и заменяете в ссылках yandex.ru на 77.88.21.11 (или любой другой их айпишник). Теоретически это тоже «равнозначно DNS ответу» :)
Не равнозначно, поскольку retracker.local изначально задуман и сделан именно для провайдеров, определяющих свой внутренний трекер.
Ну представьте что вы не Яндекс заменяете, а внутренний сайт своего провайдера.
Ну например. В нашей локальной сети все внутренние сайты расположены в зоне local. Там теоретически можно было бы проворачивать то же самое. Я считаю что замена домена в пользовательском трафике — не очень правильный способ направлять людей на нужные IP-адреса. Для этого существует DNS.
Проблема в том, что а) не все трекеры поддерживают добавление retracker.local б) наличие зоны .local у провайдера противоречит стандартам и нарушает работу этой зоны у клиентов, о чём писал и я, и другие.
Поэтому как раз ваш вариант выглядит некорректным.
Кстати, про «поддаётся контролю со стороны пользователя» в статье ничего не сказано. Судя по правилам ipfw, в middleman перенаправляются все lan-пользователи без исключения. Разве пользователь может контролировать эту фичу? Или под контроленм Вы понимаете возможность вручную удалить ретрекер из пришедшего файла? :)
Ну… э-э-э… да. :) А ещё может в hosts указать 127.0.0.1 для этого ретрекера. :)
Хотя ваша идея мне нравится. Надо будет в личном кабинете добавить лишнюю галочку «торренты быстро/торренты неизменно». Спасибо.
Хороший пример нормальной работы мозга специалиста.
Успехов :)
Оригинальное решение. Везде бы таких админов в домашние сетки.
Всегда не любил мелкие сети за то, что админы там творят что хотят. С какой стати МОИ файлы должны кем-то модифицироваться без моего согласия и к тому же сохраняться на стороннем ресурсе? А пароли и логи аськи вы не храните? Есть же соответствующий скрипт :)
Ой да ладно. Вам Microsoft при обновлении впаривает кучу непонять, чего, а логи аськи всяко собирает сама Mirabilis, или кто там сейчас ей владеет?

torrent же по самой своей идеологии штука автогенерируемая и автомодифицируемая. Это только у принципиальных трекеров там может стоять только их адрес.

Ну, а если Вам нужна неприкосновенность в публичных сетях, пользуйтесь HTTPS и SSL.
Сохранение не обязательно, оно у меня для обезличенной статистики ведётся.
А модифицироваться оно должно хотя бы для того, чтобы вы лезли не на retracker.local, а на нормальный адрес ретрекера. Если вам так легче, воспринимайте это как некий аналог внутреннего DNS. :)

P.S. А сеть в 50 000 абонентов тоже относите к мелкой?
Шизоидных линуксоидов везде хватает :) В более крупных сетях их обычно контролируют.
У Суммы так же организовано?
А как же магнеты?
А вообще, с позиции потребителя — против таких действий. Согласен с комментарием выше.
А магнеты никак, им по определению трекер не обязателен.
Там есть поле tr, если не ошибаюсь, в которое можно прописать адрес трекера, и тогда клиент начнет его использовать, что вам выгодно ;)
Главный же тут вопрос, imho, должен быть таким — а как же рейтинги?
Так ведь не заменяют все announce urls, а лишь добавляют еще один, так что с рейтингом все в порядке
И даже более того, рейтинг взлетает — по локалке отдаётся быстрее.
А оно не портит .torrent с закрытых трекеров, где за добавление ещё одного announce url могут и забанить?
Было у меня такое опасение, но его развеяли там же, да и практика подтвердила — info_hash не изменяется, а его и проверяют закрытые торренты. Другими словами, не портит и не служит причиной бана. :)
Впрочем, ничто не мешает добавить в скрипт соотвествующий if с пропуском private торрентов.
уТоррент для приватных торрентов использовал только первый трекер из списка. Кажется с версии 1.8 началось. Как сейчас — не знаю.
Подскажите, а как они это определяют? Не сарказм — праздное любопытство, а есть ли такая возможность.
А вот это лучше спросить у них. На тех же blackcat-games что-то подобное в правилах есть.
Уже не помню, надо спецификацию читать.
Благими намерениями… оно еще и «попутно сохраняет файл на диск». А можно еще рекламные блоки в html дописывать. А за техническую сторону — пять, очень интересно читать.
Попутно шлет файл по почте ТемКтоСледит :)
Им тоже нужно качать торренты быстро :)
> На несовместимость .local с zeroconf в данном случае можно закрыть глаза, поскольку в идеале DNS-запросы клиента с включенным zeroconf даже не должны доходить до нашего сервера.

Такие, как Вы «одмины» закрывают на это глаза, а у клиентов потом zeroconf автоматически отключается. Конечно, «запросы не доходят». Потому что Ubuntu, например, честно сообщает «У вашего [криворукого] провайдера в DNS'е [ВНЕЗАПНО] зона .local, поэтому мы avahi отключаем. упс.»

cadmi, ты чего такой сердитый? ;) Обрати внимание, что я специально уделил внимание на вопрос совместимости в статье.
Расскажи-ка лучше подробности:
— Какого фига Ubuntu засылает DNS-запросы зоны .local к моему DNS'у, если ты его должен поднимать только внутри своей сети?
— Что именно сообщает об отключении зоны .local (как раз сейчас сижу перед ноутбуком с Ubuntu и avahi, проблем таких не наблюдаю)

Могу и отключить зону, она в общем-то, для backward compatibility сделана.
«специально уделить внимание совместимости» — это нифига равно «не обращать внимания, закрывать глаза» :)
у вменяемых админов и retracker.local работает и zeroconf не выключается. и мы с тобой оба понимаем, как это можно сделать :)

но вот у меня дома оба хоумпрова (бывший и текущий) сделали через ж… приду домой, сделаю скриншот, как именно сообщает.
Эм… ты можешь смеяться, но пока что-то не особо понимаю. Закрыть мультикаст с клиента, чтобы он не лез запросами .local?

Давай, приобщай к «вменяемым админам». ;)
да ну. попросту не делать в DNS'е зону .local :)
Тогда как работает retracker.local? :D
Все почему-то делают у себя на bind'e зону именно .local, а в ней запись retracker A x.x.x.x

Правильнее сделать зону retracker.local, так и назвать. а в ней, запись A, ну как делают «для сайтиков, чтобы без ввв». Почему это не доходит до большинства, я честно говоря, даже не понимаю.

Наверное потому, что для этого надо думать головой, а не копипастить «инструкцию с торрентс.ру» :)

Вспомни, когда я написал про фейл с .local на nag.ru, даже тамошняя публика начала кидаться помидорами, «да пофигу, это никто не использует». А казалось бы, там то мозгов по определению побольше. Я еще объяснял им там, «подождите, присунет Microsoft очередной апдейт, после которого windows начнут ругаться, тогда запоёте» :)
Согласен.
Именно поэтому, как выяснилось, я и сделал год назад у себя зону retracker.local, а не .local:

[dyr@home-vr ~]$ dig +noall +answer ANY retracker.local
retracker.local. 86400 IN A 10.78.78.2
retracker.local. 86400 IN SOA ns2.smart. dyr.smartspb.net. 1 10800 3600 604800 3600
[dyr@home-vr ~]$ dig +noall +answer ANY local
[dyr@home-vr ~]$


Так что я всё-таки об этом тогда подумал. :)
Т.е. ретрекер всё таки возможно поднять так, чтобы он не противоречил стандартам? )
Остался ещё пункт а — не все трекеры добавляют retracker.local. А так да.
Может я чего не так делаю, но у провайдера зона retracker.local, но милая убунта не хочет обращаться к внешним днс, а скармливает всё своему avahi… Это нормально? У себя поправил конфиги резолвера.
Всё же даже зона retracker.local — это по-моему костыль, который до конца не решает конфликт.
Вот зарезервирована зона .local в протоколе mDNS (Multicast DNS) и нечего её было брать для добавления на обычный DNS-сервер.
Предложили бы изначально во все torrent-файлы добавлять announce-URL retracker.bittorrent/announce и заводили бы на всех DNS-серверах в локалках свою зону bittorrent и никаких бы конфликтов с протоколом mDNS не было бы.

А чтобы после неудачной попытки разрешить имя через mDNS линуксовый Avahi всё же передавал это имя для дальнейшего разрешения через обычный DNS, могу вам предложить открыть под рутом конфиг /etc/nsswitch.conf и в строке hosts: удалить фрагмент [NOTFOUND=return], который как раз там прописан после mdns4_minimal и перед dns.

Скорее всего, можно даже ничего не поднимать, полностью соответствовать стандартам, и всё будет работать. Идея (только что придумал) такая: модифицируем код клиента, чтобы он, вместе с обычным анонсом на трекер, слал ещё один точно такой же анонс в DHT, только вместа инфохэша использовал
ХЭШ(ИНФОХЭШ_ИСХОДНОГО_ТОРРЕНТА + ВНЕШНИЙ_IP_КЛИЕНТА)
А в качестве своего IP указывал локальный IP текущего устройства.

Естественно, если локальный IP — внешний, это всё делать не нужно.

Понимаете, да? Если внешний айпи у двух клиентов совпадает, то они, вероятно, сидят из одного NAT'а, и смогут через обычную DHT, без всяких retracker.local и патчей узнавать локальные IP друг друга.

Как вам? Как по мне, выглядит красиво. И если DHT позволяет указывать в качестве своего IP что угодно — должно сработать. Но нужна поддержка в клиентах. Я мог бы попробовать в qBittorrent добавить такое, например.

UPD: Смотрю в исходники libtorrent-rasterbar, файл src/kademlia/dht_storage.cpp

        void announce_peer(sha1_hash const& info_hash
            , tcp::endpoint const& endp
            , string_view name, bool const seed) override

— выходит, в DHT действительно можно сохранить произвольную пару IP:port для некоего хэша. То есть концепция рабочая.

> А в качестве своего IP указывал локальный IP текущего устройства.

Тут неточность. Правильно: «А в качестве IP указывал провайдерский IP из локального диапазона».

Как определять провайдерский IP из локального диапазона, если клиент за роутером? По UPNP. Если UPNP выключен или не отвечает, использовать локальный адрес устройства.

Возможное решение для самого частого кейса: Windows + uTorrent. Приложение, висит в трее, работает ретрекером на локалхосте, данные хранит/получает из DHT, как описано выше. Также следит, чтобы в hosts retracker.local смотрел на localhost (можно использовать 127.0.0.14 или что-нибудь такое, чтоб не мешать пользовательским HTTP серверам), если нужной записи нет, даёт создать одной кнопкой. И ещё пусть проверяет, что uPNP на роутере работает (если нет, рассказывает, как настроить).

Заинтересовала статья.
Но немного в другом русле. Нужно на локальном уровне как раз минимизировать трафик с торрентов, в сквиде как-то руки не так стоят.
Поделился с коллегой, в итоге разбомбил он ее в пух и прах.

x2 (13:23:46 14/10/2010)
блин из-за твоей стать полчаса угрохал на анализ, судя по скрипту этот мудила недоговаривает))), если бы я был в его домашней сетке — я бы ему клавой зубы почистил бы))

x2 (13:25:39 14/10/2010)
он делает просто- ты например хочеш скачать порно с сайта порнолаб и просиш через файл анонс этой порнушки — твой файл анонса проходит через его торент и в него уже втсавлен локальный торент — то есть все в локалке видят что ты заанонсировал качающуюся порнушку и все могут подключиться для скачки у ТЕБЯ этой порнушки

x1 (13:26:11 14/10/2010)
т.е. некий аналог dht?

x2 (13:26:37 14/10/2010)
мало того что тебя с потрохами сдают)) так он еще анонсирует себя на порнолабе — он подменяет хеш файл — да блин за такое и забанить к хери могут притом навсегда

x2 (13:28:02 14/10/2010)
нет причем тут дхт, в дхт то отсальные незнают что ты качаеш и незнают что качать — а у него стоит трекер который аннсирует все твои закачки со ВСЕХ в мире торентов — ты скачал например фильм с рутрекера а об этом все знают в локалке и тупо гачина/т качать с тебя

x2 (13:28:36 14/10/2010)
то есть такой себе камунизм с разводом лохов

x2 (13:30:01 14/10/2010)
приватности пипец, тылох так как ты использовал инет на скачку фильма а потом просто раздаеш в локалке всем нашару — ведь ты неотключаеш его — нужно ведь для коэфа его раздать

x2 (13:31:23 14/10/2010)
самое прикольное что теоритечиски если закрытый трекер не сообразит то ты на локалке можеш нечестно накрутить коэфф так как хеш файл подменен — думаю скоро какаято подсеть будет забанена на многих закрытых трекерах)))

x2 (13:32:39 14/10/2010)
парень канешно умный, но мудак,


Рискую конечно, но хочется предупредить энтузиастов, которые это реализуют.
По моему этот собеседник нифига не понимает в устройстве торрентов.
Передайте вашему коллеге, что он сам мудак может почитать внимательнее спецификацию. За год работы механизма не поступило ни одной жалобы от пользователей,, банящий pornolab вообще входит в десятку самых часто используемых. :)
# for i in `find /home/torrents/patched/ -type d`; do echo -n "$i" && ls -1 $i| wc -l; done | awk '{print $2" "$1}' | sort -rn | head -n 10
24103 /home/torrents/patched/dl.rutracker.org
7817 /home/torrents/patched/dl.torrents.ru
6184 /home/torrents/patched/tfile.ru
3744 /home/torrents/patched/kinozal.tv
2928 /home/torrents/patched/rutor.org
2872 /home/torrents/patched/torrents.thepiratebay.org
2583 /home/torrents/patched/www.tfile.ru
2582 /home/torrents/patched/www.torrentino.ru
2531 /home/torrents/patched/pornolab.net
1032 /home/torrents/patched/www.rutor.org


Ну и приватность при раздаче торрента — это уже гомерически смешно.
а) Хеш файла не меняется
б) Список пиров остается тот же, только появляется возможность обмениваться в нутри локальной сети (что не влияет на рейтинг и не является нарушением условий трекера, если конечно админы трекера не параноики)))
в) Приватность в торрентах вообще в принципе вещь абстрактная и вряд ли обмен внутри локальной сети шибко повлияет на неё.
г) Пусть человек еще раз перечитает статью, а особенно понятия ретрекера (хоть в википедии) и вообще принципы устройства торрентов. Ибо после фразы:
нет причем тут дхт, в дхт то отсальные незнают что ты качаеш и незнают что качать — а у него стоит трекер который аннсирует все твои закачки со ВСЕХ в мире торентов — ты скачал например фильм с рутрекера а об этом все знают в локалке и тупо гачина/т качать с тебя

хотелось долго смеяться.
Список пиров остается тем же, только добавляется +3 шанс к тому, что будет засвечен внутренний, а не внешний адрес, который и является единственным нежелательным последствием для любителей скачивать порнографические материалы с участием Черного Вл. Любой торрент-клиент новее 2004 дает то же самое, любой ресолвинг внутренних адресов для «белых» IP дает то же самое, любой «белый» IP дает то же самое.

И чем еще сие может угрожать приватности?
Если вы боитесь обычных юзверей, то да, приватность в каком то смысле страдает. Но как они видят вас, так и вы видите их.
Если вы боитесь некоторых органов, то наличие вашего локального адреса у них в кармане или его отсутствие (временное) вас не спасет.
Более того, как раз локальный трекер увеличивает приватность — мониторинг трафика происходит обычно только на точке выхода трафика в интернет, но не в локальной сети. Таким образом становится возможным скачивать и раздавать трафик хоть вообще без Большого Брата.
В любом случае изменение пользовательских данных это не правильно.
За такое надо «клавой зубы чистить».
Это всё тот же вопрос, кто давал вам право изменять чужую информацию?
Прошу Вас, не давайте ему на хабр, троллей у нас и так полно.
то есть по сути куча торрентов с пасскеями клиентов хранятся где-то у кого-то? забавно угу
а вот насчёт пасскеев корректное замечание, да.
на которое вам сейчас ответят, что провайдер и так всё знает, хоть пасскей, хоть не пасскей ) поэтому нечего метаться :)
да незачем их там хранить. перехватил, пропатчил, отдал клиенту, стер. можно вообще не сохранять файл на диск, все делать в памяти (или на рамдиске). для «статистики использования трекеров» можно прямо в скрипте-патчере делать +1 к очередному трекеру.
Низя так… :) Админам же хочется покачать чего-нибудь без расхода рейтинга! :)
у админов обычно seedbox столько рейтинга наваривает, что впору его засаливать и закусывать! :)
По идее, раз уж торрент файлы нужны для статистики, можно вести её просто в SQL, удаляя сами файлы сразу после учета.
Ну не доделал я это, не доделал. Каюсь.
Отличный повод перейти на https-трекеры (да, таких достаточно). В статье относительно безобидная модификация, но теоретически провайдер может сделать что угодно.
Чего только не делается, лишь бы не раздавать пользователям белые IP адреса.
В нашем городе уже года три ни у одного провайдера нет такого понятия «внутренний адрес». Все айпи белые (чаще всего статические) и соединение всегда идет напрямую. Соответственно никакого геморроя с ретрекерами и т.п.
Не понял… А какая связь между белыми адресами и повышением скорости работы p2p файлообмена в рамках одной локалки?
У компьютера в свойствах сетевухи прописывается статичный белый айпи. Больше никих других айпи нет. У провайдера сеть построена таким образом, что все соединения между его абонентами проходят внутри его сети на скорости 100 мбит (т.е. не доходят до шейперов). Поэтому на любом трекере пиры, принадлежащие этому провайдеру, легко подхватываются и качается/отдается со скоростью 100 мбит.
Это я понимаю, у меня такой же провайдер (с внешней статикой, без всяких PPTP/PPoE), и скорость скачивания за счет пиринговых сетей достигает 100 Мбит — при официальном тарифе в 5 МБит… :)

Вопрос в другом — насколько я понимаю, ретрекер полезен не только для обмена трафиком абонентов, сидящих за NAT'ом, но и в случае прямых адресов позволяет быстрее найти друг друга.

Я ошибаюсь?
ага, на абстрактном новафильм.тиви выложили свежую серию какого-нибудь «лай ту ми». 20000 (двадцать тысяч) обладателей белых статических ip пошли эту серию качать. а трекер выдает максимум 20 (двадцать) пиров каждому. и скорее всего — иногородних.

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

З.Ы. все имена трекеров, сериалов и количества пиров в этом комментарии взяты абсолютно из головы, не имеют ничего общего с реальными и упомянуты только для иллюстрации работы механизма :) более того, для примера специально взят трекер, «сам по себе» не поддерживающий retracker.local. тогда как описанный в статье механизм сделает «хорошо» и для торрентов с него тоже.
Интересно, как вы такую щедрость RIPE'у объясняете.
А есть ли цифры общей статистики по сэкономленному внешнему (для сети) трафику, за счет форсирования обмена между абонентами?
Нету.
Целью было не столько экономия трафика, сколько повысить скорость обмена абонентам.
UFO just landed and posted this here
А нет такого тарифа. Есть 15Мбит за 900 рублей.
UFO just landed and posted this here
Повторюсь ещё раз — это сделано не для экономии трафика прежде всего, а для бонуса увеличенной скорости торренто-обмена.
UFO just landed and posted this here
Шифровать надо всё, шифровать. Чтобы всякие там не «заоптимизировали» ваш трафик )
Не боись, разшифруем и заоптимизируем. )
UFO just landed and posted this here
UFO just landed and posted this here
Чёрт, по-моему, я вам выдал ссылку на ваше же решение :)
Sign up to leave a comment.

Articles