четверг, 27 июня 2013 г.

Торренты запрещают. Что теперь делать?! Уходим в андеграунд, или Kademlia жива!

Давеча в начале месяца власти решили таки запретить нам скачивание наших любимых фильмов, дабы мы их таки не скачали. Это не может не "радовать". Так что-же нам делать?

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

На самом деле, файлообмен возможен между любыми двумя участниками, имеющими полноценный доступ в интернет. Т.е. теоретически мы, имея доступ в интернет, можем с лёгкостью скачать что угодно, у кого угодно. Однако, имеются и проблемы:

  1. Время. Один из компьютеров должен быть включён в Сеть 24/7/365.
  2. Адрес. Неплохо-бы знать, откуда нам собственно нужно качать наш любимый контент. Понятное дело, что никакие узлы не горят желанием публично выкладывать свои адреса, дабы избежать сложностей.
  3. Далеко не все клиенты имеют сегодня полноценный доступ в Сеть. Многие "сидят за NAT'ом", т.е. имеют возможность работать лишь как клиенты (если вы "сидите за NAT'ом", то вы можете лишь скачивать откуда-то что-то по вашему запросу, или заливать что-то кудато по своей инициативе). "NAT" в кавычках потому, что "за ним", на самом деле находятся все пользователи Интернета(и не за одним NAT'ом), но не все NAT'ы одинаково полезны. У каждого клиента имеется свой IP адрес, этих адресов немного, и они стоят денег. А посему, многие провайдеры выдают один IP адрес на множество клиентов. Очевидно, запрос К такому клиенту не дойдёт, потому-что шлюз провайдера не знает, к кому он именно, среди Over9000 таких же. Если вы "за NAT'ом", то вы не сможете меняться файлами с такими-же бедолагами как вы (исключения есть, но они сложно реализуемы на сегодня). К счастью, примерно половина пользователей интернета имеет на сегодня полноценное подключение, а следовательно, вы теряете не так много(а именно около половины источников)
Все эти проблемы можно решить привлечением третей стороны.

Исторически первыми, среди массового файлообмена, были FTP серверы. Такой сервер представляет собой обычный компьютер, который работает не совсем в обычном режиме. Во первых он работает 24/7/365. Во вторых, он имеет полноценный широкополосный интернет, причём на отдачу (часто многие провайдеры умалчивают о том, сколько вы можете отдать, по той причине, что большинство клиентов только забирает). FTP серверы публиковали свои координаты на разных форумах, и народ оттуда спокойно качал файло. Это было очень давно, задолго до наших лет(в прошлом веке). Сейчас все такие сервисы давно закрыты, ибо никто в здравом уме не желает сидеть в тюрьме непонятно за что(один человек просто физически не сможет проверить законность контента, что ему присылают, а ответственность за CP появилась задолго до интернетов).

Когда, в начале нулевых, прикрыли все FTP, народ ринулся искать иные пути обмена файлами. Первое время все ринулись на офф файлообменники, которые предлагали бесплатный обмен в качестве бонуса/завлекухи для платных клиентов. Вот например на этот. Владельцам сервисов это пришлось не по нраву, и они быстренько исправили ситуацию, в корне задавив такую вольность.

К счастью, к тому времени появилось достаточно много узлов, которые обладали анлимом, и могли без проблем меняться файлами друг с другом непосредственно. Но проблема №2(см. выше, невозможность узнать адрес источника) осталась. Эта проблема была решена с привлечением третей стороны, а именно треккера.

Логика работы треккера довольно проста: каждому файлу присваивается уникальный хеш(фактически -- очень большое целое число), и именно этот хеш и хранится на треккере. Кроме хеша также хранятся и IP адреса всех источников. Даже если вы ещё ничего не скачали, вы всё равно являетесь источником, хотя и в потенциале, и будете вынуждены не только брать, но и раздавать, во всяком случае пока качаете файл.

В юридическом плане всё тоже получилось неплохо: на треккере нет, и никогда не было никаких файлов, только их хеши, и IP источников. Потому треккер ну никак нельзя было привлечь за распространение фильмов, не та статья. До недавнего времени никто не мешал делится легальным покупателям содержимым купленных ими дисков(если конечно это делалось не с  целью наживы, и если это не CP).

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

В ближайшее время тоталитаризм грядёт и в Россию, и нам срочно надо думать, что-же делать?

Ну для начала подумаем, как именно будет происходить борьба: лентару говорит, что всё будет просто: предупреждение, потом, если не осознал, штраф 5 тыщ. Не сложно догадаться, что все осознают, и просто снимут с раздачи то, что они там закачали. А если кто не снимет, то штраф 5000руб никак не окупит оперативно-следственную работу по выявлению "пирата". Лога провайдера для этого точно недостаточно, ибо на треккерах полно легального контента. Пруф. Это ведь надо будет конкретную слежку/прослушку ставить. Конечно это оправдано для поимки убийцы/педофила, но для поимки пирата это слишком.

Какаим-же образом будет выполняться постановление Правительство СР? Очевидно лишь одним: придётся заблокировать треккеры, если не все, то хотя-бы самые крупные (этого более чем достаточно, ибо 3.5 юзерам остальных будет просто неоткуда качать. А если их треккер станет популярным, то и его быстро залочат).

Технически это реализовать очень просто, просто запретить соединения от клиентов к IP треккера. ВСЁ.

И что-же делать?

Да очень просто, если нельзя сделать один большой треккер, давайте его порежем на 100500 маленьких, и будем поддерживать каждый кусочек самостоятельно!

Именно в этом и заключается идея Kademlia.

Реализация Kademlia

Всё довольно просто: каждому файлу, как и на треккере, присвоен md4 хэш. Но хеш присвоен не только файлам, но и самим клиентам(случайным образом). Основная идея Kademlia(как и любой DHT) заключается в том, что-бы считать каждого клиента узлом некого гиперкуба. В Kademlia гиперкуб 128и мерный, а следовательно имеет 2^128=340282366920938463463374607431768211456 вершин. Очевидно, что практически все из них пустые. Также очевидно и то, что двигаясь только по рёбрам гиперкуба, мы можем пройти от любой вершине к любой другой не более, чем за 32 прыжка. Но самое главное, что мы всегда можем найти кратчайший путь(расстояние между узлами очень легко посчитать: оно равно числу разных бит в хешах, если их записать в двоичной СС). Конечно всё это верно, если наши узлы расположены равномерно. Но это так и есть.

Подключение к Сети

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

Поиск хеша

Поиск осуществляется с помощью UDP запроса, который отправляется в адрес того соседа(из 1000), хеш которого ближайший к искомому. Сосед поступает также. В итоге, уже через ~10…15 прыжков ответ достигает узлов, хеш которых ближе всех к искомому. Именно там и встречаются запросы  всех клиентов, которые что-то ищут. И там же хранятся адреса ищущих. Они-то и отправляются тому, кто это искал. Ну а далее ищущий обращается к тем, у кого что-то есть, уже напрямую(в случае, если источник "за NAT'ом", то он сам обращается к ищущему).

Хеш можно вычислить от чего угодно, а вовсе не только от файла целиком. Сам файл делится на блоки (по 10Мб), каждый из которых имеет свой хеш. Эти блоки тоже можно искать. Кроме того, каждое имя файла дробится на слова, и хеши слов тоже публикуются, а потому, в Kademlia можно искать и по имени файла, а не только имея ссылку. Потому Kademlia НЕ нуждается в сайтах для поиска, которые тоже можно забанить. Кроме имени, размера, и хеша файла, в Kademlia предусмотренна и иная информация о файле(рейтинг, комментарий, параметры мультимедиа, если ОС смогла их распознать, например разрешение экрана, и т.д.). Искать по ней нельзя, но можно фильтровать.

Число источников

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

Вуалирование

Вуалирование == шифрование. Однако не обычное, а специальное, в  котором ключ лежит рядом с данными. Смысл его вовсе не в  защите информации от чтения врагами, а в том, что-бы не допустить провайдеру блокировать трафик. Пакеты в Kademlia имеют известную и документированную структуру, а следовательно их очень просто заблокировать. Если-же они зашифрованы, то для поиска необходимо расшифровать ВСЕ пакеты ВСЕХ клиентов. Это возможно лишь теоретически, но никак не на практике. На практике, пакеты Kademlia имеют содержимое неотличимое от случайного мусора, и случайный размер.

Заключение

В заключение я лишь могу дать ссылки на оффсайт emule, там же вы найдёте необходимую документацию и т.п.

Имеется также кросплатформенный клиент aMule, имеющийся в репозиториях всех популярных Linux'ов(также есть версия его же для apple). Естественно, amule работает не только GUI клиентом, но и демоном (в составе есть удалённые морды, GUI, CLI, и web). Ссылку намерено не даю, ибо программы необходимо ставить из репозитория, а не "бесплатно и без СМС". В силу почти полного совпадения кодовой базы, документация по eMule подходит и для aMule (за небольшими исключениями, которые не играют роли).

За сим -- желаю удачи.

Свирепой шестерёнкой в механизме государства
Армейской мясорубке не давай себя сжевать.
Назло!!!!!!!!!
поперёк!!!!!!!!!
Назло!!!!!!!!!
поперёк!!!!!!!!!

Сторонникам порядка навреди как можно больше
В проигранной  войне сопротивляйся до конца.
Назло!!!!!!!!!
поперёк!!!!!!!!!
Назло!!!!!!!!!
поперёк!!!!!!!!!

Шагай на красный цвет и нарушай правопорядок
Законам и запретам поступай наперекор.
 Назло!!!!!!!!!
 поперёк!!!!!!!!!
Назло!!!!!!!!!
поперёк!!!!!!!!!

На всякое насилье отвечай сопротивленьем
В безликом окруженьи будь всегда самим собой.
Назло!!!!!!!!!
поперёк!!!!!!!!!
Назло!!!!!!!!!
поперёк!!!!!!!!!


(Гражданская Оборона)

понедельник, 17 июня 2013 г.

подключение яндекс-диска в Linux.

что-то слишком уж много стало мануалов, и ни одного нормального. Вот напишу шпаргалку на будущее.

step by step

1. понадобятся права root'а. Во первых для установки davfs2.

2. для Slackware Linux нужно предварительно создать пользователя и группу.

# groupadd -g 230 davfs2
# useradd -u 230 -d /var/cache/davfs2 -g davfs2 -s /bin/false davfs2
(для остальных дистрибутивов этот пользователь сам создаётся, хотя это нужно проверить).

Теперь можно ставить davfs2 (slackbuilds.org)

3. основной юзер(у меня drb) должен входит в группу davfs2. (добавить можно командой usermod, или просто подправив /etc/group)

4. для монтирования нужно добавить запись в /etc/fstab

https://webdav.yandex.ru   /home/drb/yandex  davfs   noauto,user           0   0

вам нужно будет поменять имя каталога на нужное. Именно туда и смонтируется yandex.disk. У меня это /home/drb/yandex

5. теперь права рута нам не нужны 

6. Создаём точку монтирования  /home/drb/yandex (простой каталог, создаём НЕ от рута, а от себя).

7. создаём каталог ~/.davfs2 (права 0755, как обычно)

8. копируем туда /usr/share/davfs2/secrets и /usr/share/davfs2/davfs2.conf

9. назначаем права

chmod -v 0600 ~/.davfs2/secrets

10. забиваем в этот файл своё имя и свой пароль к учётке яндекса. Например у меня почта на яндексе: emulek@yandex.ru, потому я добавил такую запись:

/home/drb/yandex             emulek       мой_пароль

11. теперь можно монтировать обычной командой

mount ~/yandex

которую можно внести в автозагрузку например.

12. в конфиге есть параметр  debug most, который позволяет посмотреть, по каким причинам каталог не смонтировался. Пароль вводить ессно не нужно.

UDP: Зачем?
Да, действительно, доступ к я-диску можно получить иначе. Однако, _любой_ иной способ, кроме монтирования, имеет существенный недостаток: невозможно работать с диском иначе, как этим способом.

Монтирование делает из диска обычный локальный каталог, с которым может работать _любая_ программа, в т.ч. dolphin/rsync.

У меня проблема с бекапами, которые мне необходимо делать автоматически, иначе я про них забываю. Т.о. запускать для них дельфин для меня неприемлемо(и уж паче того wine).

Кроме того, локальные бекапы можно хранить в открытом виде, но чужим облакам я не верю. Яндекс убрал пункт, запрещающий шифрованные файлы. Потому ничего не мешает хранить файлы в шифрованном виде. Однако, программы вроде GnuPG про яндекс-диск не в курсе, за то отлично работают с обычными каталогами, в частности и из скриптов. Используя асимметричное шифрование, можно легко добиться автоматической работы (ибо зашифровать файл может кто угодно, а именно это и нужно).