Основы разработки клиента сети I2P

Данная статья предназначена для тех, кто хотел бы разработать собственного I2P клиента «с нуля». Предполагается знакомство с основными концепциям и понятиями I2P. На настоящий момент на это счет имеется достаточно документации и статей, в том числе и переведённых на русский язык. С другой стороны имеется официальная документация, достаточно хорошо описывающая протоколы и форматы сообщений. К сожалению она носит разрозненный характер, при этом многие неочевидные вещи там отсуствуют. Данная статья написана в первую очередь на основе изучения и отладки официального I2P джава-клиента. Конечной целью является реализация полностью на C++. Исходный код проекта в текущем состоянии располагается на github.

Используемое шифрование


Для построения собственного I2P маршутизатора необходимо наличие реализации следующих алгоритмов шифрования:
  1. Эль-Гамаль (ElGamal). Ассиметричное шифрование, основанное на возведении основания в степень по модулю. Основание и модуля являются фиксированными константами для всей сети I2P. Помимо блоков стандартного размера в 514 байта, также используются блоки нестандартного размера в 512 байт.
  2. Диффи-Хельман (Diffie-Hellman) для получения общего ключа симметричного ключа шифрования путем обмена публичными ключами. Используются те же самые ключи что и для Эль-Гамаля.
  3. DSA для создания и проверки электронной подписи
  4. AES а двух режимах: CBC с использованием ключа шифрования и вектора инициализации (IV), ECB для шифрования собственно IV длиной 16 байт
  5. SHA256 для вычисления хэшей
  6. Adler32 для вычисления контрольной суммы сообщений


Основные протоколы


I2P сеть состоит из 4-х основных уровней:
  • Транспортный уровень. Это зашифрованные Интернет соединения TCP/IP или UDP. Включает в себя установку соединений и шифрование.
  • Тоннели. «Окна» узлов во внешний мир, располагающиеся на других узлах и позволяющие скрывать свое истинное местоположение. Состоят из последовательности узлов, соединенных между собой протоколами транспортного уровня. Тоннель можно упрощенно представлять себе как цепочку прокси-серверов для анонимизации как клиента так и сервера.
  • «Чеснок». Передача сообщений или последовательности между двумя конечными узлами произвольным маршрутом и тоннелями. Характеризуется идентификаторами сессий и асссиметричным, а, после установки сессии, симметричным шифрованием
  • Протоколы прикладного уровня для передачи пользовательских данных между узлами.

Каждый уровень добавляет свое собственное шифрование разного назначения. Шифрование транспортного уровня скрывает трафик от провайдера, туннелей — содержимое и направление от промежуточных узлов туннелей, «чеснок» — от конечных узлов тоннелей при передаче сообщений между тоннелями.

Транспортный уровень


Для того чтобы установить соединение транспортного уровня требуется знать IP адрес и порт. Существует список известных узлов, называемый netDb, изменяющийся в процессе работе, информация о новых узлах поступает от других узлов. Первоначально список узлов скачивается со специальных сайтов, адреса которых явно перечислены в файле router/networkdb/Reseeder.java. Протокол, работающий поверх TCP/IP называетcя NTCP, а поверх UDP — SSU. Помимо некоторых отличий в установке соединений, SSU из-за пакетной природы поддерживает разбивку длинных сообщений на несколько фрагментов. Передаваемые сообщения состоят из заголовка, I2PN сообщения (о протоколе I2NP ниже) и контрольной суммы. Периодически передается специальное сообщение, содержащее текущее время с целью синхронизации. При установке соединения происходит обмен публичными ключами маршутизаторов, на основе которых по алгоритму Диффи-Хельмана вычисляется общий ключ для AES шифрования каждый на своей стороне.

Тоннели


Тоннели всегда однонаправленные — все сообщения могут передаваться только от входного узла (Gateway) к выходному узлу (Endpoint). В зависимости от того какой конец тоннеля принадлежит его владельцу, обладающему всей полнотой информации о тоннеле, тоннели делятся на входящие (владелец — выходной узел) и исходящие (владелец — входной узел). Промежуточным узлам тоннеля неизвестно, является ли тоннель входящим или исходящим, единственное действие, осуществляемое промежуточным узлом, это шифрование сообщения своим ключом шифрования и передача следующему узлу. Отсюда вытекает важное следствие: последовательное расшифрование сообщений тоннеля должно осуществляться его владельцем, поскольку только у владельца есть ключи шифрования всех промежуточных узлов. Данный факт достаточно тривиален для входящих тоннелей, т. е. получив сообщение выходной узел должен его последовательно расшифровать, однако для исходящих тоннелей оригинальное незашифрованное сообщение должно быть последовательно расшифровано перед его отправкой. Тоннели, для которых данный узел не является владельцем, называются транзитными. Транзитные тоннели передают чужой трафик и необходимы для поддержки функционирования всей сети I2P, тем самым превращая узел в маршутизатор. Узлы тоннелей используют AES шифрование с тремя различными ключами: один используется для шифрования ответа узла при создании тоннеля, а два других для передачи данных через тоннель: один ключ шифрует сами данные, а другой шифрует вектор ипициализации (IV) для шифрования данных. При этом IV шифруется тем же самым ключом дважды: до шифрования и после, называется это двойным шифрованием (double encryption). Узел получает эти два ключа в относящейся к нему записи сообщения создания тоннеля, зашифрованной его публичным ключом с помощью Эль-Гамаля.
Внутри тоннелей передаются исключительно сообщения TunnelData, вообще говоря состоящие из нескольких фрагментов. Для передачи между тоннелями используется сообщение TunnelGateway. Хотя в официальной документации написано, что для двустороннего соединения необходимо как минимум 4 тоннеля (2 входящих и 2 исходящих), на самом деле передавать сообщения через исходящие тоннели необязательно, а можно отправить сообщение TunnelGateway входному узлу нужного входяшего тоннеля.
В сообщении TunnelData контрольная сумма вычисляется из содержательных данных, следующих за нулевым байтом и присоединённым к нему не зашифрованным IV.

Протокол I2NP


Обмен данными внутри сети I2P происходит с помощью I2NP сообщений разных типов. Каждое сообщение содержит заголовок с его типом и длиной, позволяющий определить границы между сообщениями. В зависимости от типа длина сообщения может варьироваться от 20 до 64К байт. Каждый уровень использует сообщения- «обертки», содержащие внутри себя другие I2NP сообщения более высокого уровня. Для тоннелей такими «обертками» являются сообщения TunnelData для передачи внутри тоннелей и TunnelGateway для передачи между тоннелями. Для «чеснока» — Garlic. Большую часть I2P трафика представляют собой следующий вложенные сообщения:
Data->Garlic->TunnelData.
Как правило сообщения передаются через тоннели, хотя могут передаваться и напрямую между маршутизаторами, в частности для первоначального создания новых тоннелей. Также маршутизаторы обмениваются сообщениями DatabaseStore сразу после установки соединения. Сообщения между точками назначения следует передавать через «чеснок», поскольку соответствующее поле присутствует только там.

Маршутизаторы и точки назначения (destinations)


Для работы в сети I2P необходим I2P клиент, состоящий из маршутизатора, обеспечивающего доступ в сеть I2P, и точек назначения для обмена содержательной информацией. Информация о маршутизаторах  в том числе и об их IP адресах является общедоступной, более того, актуальный список  маршутизаторов можно скачать со специальных ftp-сайтов. В то же время информация о местоположении точек назначения является конфиденциальной. Информацией о точках назаначения, расположенном на данном маршутизаторе, располагает только данный маршутизатор, для все остальных получение этой информации не представляется возможным, что является одним из основных механизмов  обеспечения анонимности сети I2P.
Поскольку маршутизаторы в основном располагаются на компьютерах участников сети, то их состав все время изменяется. Поэтому маршутизаторы вынужденны постоянно поддерживать свой список другим маршутизаторов в актуальном состоянии. Этот процесс называется «зондированием» (exploratory), заключающийся в посылке запросов со случайно выбранным 32-байтным адресом специальным маршутизаторам, называемых floodfill. Предполагается что floodfill-маршутизаторы обладают всей полнотой информации о сети. Помимо все прочего floodfill-маршутизаторы постоянно сообщают друг другу информацию о найденных новых узлах.
Для запроса информации об узле используются I2NP сообщение DatabaseLookup, а для передачи самой ифмации DatabaseStore. Как правило сообщения передаются через тоннели, однако DatabaseStore передается узлом напрямую на траспортном уровне сразу после установки соединения, тем сам сообщая сети о своем существовании. В противном случае построение тоннелей для новых узлов было бы невозможно.
DatabaseStore может содержать информацию двух видов, в случае если данному адресу соотвествуют структура RouterInfo, то адрес является маршутизатором, а если LeaseSet то точкой назначения.
RouterInfo содержит публичные ключи маршутизатора, а также разнообразную служебную информацию, наиболее важной из которой являются IP адреса, порты и поддерживаемые транспортные протоколы для соединения и сведения о том является ли даныый маршутизатор floodfill-ом или нет. Поскольку RouterInfo может содержать довольно много текстовой информации, то передается заархивированным gzip-ом.
LeaseSet, содержит список входящих туннелей данной точки назначения, а также публичный ключ для шифрования «чесночных» сообщений, предназначенной данной точке назначения.

Службы прикладного уровня


Рассмотрим содержательные действия I2P клиента: анонимный хостинг онлайн ресурсов, и, соответственно, доступ к ним. Для начала попробуем получить данные с некоторого веб-сайта, например, Флибусты. На данный момент у нас имеется только 32-байтный хэш ее I2P адреса, нашей целью же является отправка HTTP-запроса, и получение ответа.
Разумеется маршутизатор с таким адресом в базе отсутствует (иначе IP адрес ресурса был бы виден всем), поэтому единственный способ отправить запрос — это какой-нибудь входящий тоннель нужного узла, существующий в данный момент времени, для чего сначала следует запросить и получить LeaseSet. В отличие от RouterInfo, который можно запросить и получить с соседнего узла на транспортном уровне, LeaseSet можно запросить и получить только через туннели, которые предварительно нужно построить. Отсюда следует неутешительный вывод, что использовать I2P сеть «по требованию» не получится, I2P маршутизатор должен быть запущен и должен постоянно заниматься построением и поддержкой тоннелей. Из-за децентрализованности сети построение тоннелей весьма непростое дело — большинство попыток создания тоннелей оканчиваются неуспехом.
Для успешного построения тоннеля необходимо два условия:
  1. Все участвующие в тоннеле узлы должны быть доступны на транспортном уровне по крайней мере предыдущему узлу в тоннеле
  2. Все участвующие в тоннеле узлы должны быть согласны построить новый тоннель. Узел может отказать в создании тоннеля, например, в силу его загруженности

Максимальное время жизни тоннеля 10 минут, тоннель может прекратить свое существование и досрочно, если участвующий в тоннеле узел ушел в оффлайн. Поэтому владельцы тоннелей постоянно посылают тестовые сообщения чтобы поддерживать список «живых» тоннелей в актуальном состоянии.
Итак, тоннели имеются в наличии и необходимый LeaseSet имеется в наличии. Теперь можно отправить HTTP запрос и он даже достигнет адресата, однако нам желательно также и получить ответ. Для этого мы в нашем сообщение должны указать наш собственный LeaseSet, тогда ответ будет отправлен нам через какой нибудь входящий туннель и скорее всего благополучно достигнут нашего узла. Поскольку через наш узел может одновременно работать несколько соединений, то каждому из них должен быть либо назначен собственный I2P адрес и сформирован LeaseSet из нескольких входящих туннелей, либо создан «разделяемый» адрес, мультиплексирующий соединения, используя специальный протокол соответствующими полями, являющийся «оберткой» над протоколом прикладного уровня. Такой протокол называется I2CP и в официальном I2P клиента используется исколючительно он, хотя для построения собственных служб это необязательно. Разумеется для доступа к Флибусте следует использовать I2CP, посколько она ожидает именно его. Однако для построения к примеру собственной торрентоподобной сети можно обойтись только I2P адресацией.

Протокол I2CP и построенный поверх него стек протоколов является отдельной темой, которой посвящена отдельная статья.
Share post

Similar posts

Comments 35

    0
    «Существует список известных узлов, называемый netDb, изменяющийся в процессе работе, информация о новых узлах поступает от других узлов. „
    Значит эти известные узлы должны иметь белые айпишники?
      0
      Нет. Это могут быть IP-адреса роутеров, определённые порты на которых проброшены на I2P-роутер. Сам этот I2P-роутер может быть за NAT.
        0
        В целом да. Иначе произвольный маршутизатор не сможет переслать ему никакое сообщение если не сможет установить с ним соединение, что резко ограничивает возможности. В первую очередь такой маршутизатор фактически не сможет участовать в передаче транзитного трафика, кроме того входящие тоннели можно строить только через маршутизаторы, с которыми уже имеется соединение.
        С другой стороны хостить, например, свой сайт можно и не имея «белого» ай-пи — достаточно надлежашим образом тоннели для LeaseSet-а.
        0
        А зачем шифровать IV, да еще и в режиме ECB?
          0
          На этот вопрос я бы тоже хотел знать ответ. Я когда на это наткнулся, то не мог понять, откуда следует брать IV для шифрования IV, пока не осознал что используется ECB (кстати этот момент в официальной документации опущен). Более того, шифровать IV нужно дважды.
          У меня сложилось впечтление, что I2P был начат студентами, пытавшимся применить на практике знания, полученные на лекциях, возможно не всегда целесообразно.
          В любом случае при разработке клиента мы не имеем возможности изменить протокол, а вынуждены реализовывать то, что есть, чтобы взаимодествовать с другими узлами сети.
            0
            А можете немного подробнее объяснить, если вам не трудно: «При этом IV шифруется тем же самым ключом дважды: до шифрования и после, называется это двойным шифрованием (double encryption)» — что имеется в виду под «до шифрования» и «после шифрования»? IV ведь не является частью открытого текста, чем IV до шифрования отличается от того, что после?
              0
              У вас имеется IV, приходящий в сообщении TunnelData, являющийся часть открытого в смысле тоннеля текста.
              www.i2p2.de/tunnel_message_spec.html

              Вы должны его, в зависимости от стороны, зашифровать/расшифровать вашим ключем для IV, затем полученное значение использовать в качестве IV для шифрования самого содержимого, затем то же самое проделать с IV повторно, потом сообщение с уже перешифрованным IV идет дальше.
                +1
                Получается, у нас изначально есть:
                — KeyIV — ключ для IV
                — KeyMessage — ключ для сообщения
                — PlainIV — открытый IV
                — PlainMessage — открытый текст

                EncryptedTempIV = AES(plaintext = PlainIV, key = KeyIV, mode = ECB)
                EncryptedMessage = AES(plaintext = PlainMessage, key = KeyMessage, iv = EncryptedTempIV, mode = CBC)
                EncryptedIV = ???
                FinalMessage = Pack(EncryptedIV, EncryptedMessage)

                Я вижу несколько вариантов того, как можно получить EncryptedIV:
                a) AES(plaintext = EncryptedTempIV, key = KeyIV, mode = ECB)
                b) AES(plaintext = EncryptedTempIV, key = KeyIV, iv = PlainIV, mode = CBC)
                c) AES(plaintext = EncryptedTempIV, key = KeyMessage, mode = ECB)
                d) четвертая смешная опция

                К первому варианту (a) — авторы точно уверены, что Encrypt(Encrypt(x)), где Encrypt(x) := AES(plaintext = x, key = SAME_KEY, mode = ECB) — это вообще хорошая идея? В голову сразу приходит пример с гаммированием и полной обратимостью в случае одинакового ключа — кто-то вообще проводил анализ того, что получается с данными, если их дважды зашифровать одинаковым ключом?

                Какой из вариантов используется на самом деле?
                  +1
                  Используется именно вариант a). Дважды тот же самый ключ.
                  Насколько я понимаю они таким образом пытались убрать IV, передаваемый открыто.
                  Согласен что идея дурацкая, как надевать два презерватива одновременно.
                  Я уверен лишь в том, что используется именно этот вариант — иначе другие узлы не смогли бы понять мои сообщения, равно как и я их.
          0
          Что нужно, что бы определить IP хоста в сети i2p? Я так понял, что i2p не дает высокую гарантию анонимности. Если я сделаю веб сайт в сети i2p, то что нужно сделать спецслужбе страны Х, что бы определить IP хоста?

          Я так понимаю, что можно просто прийти в гости всем 27 человекам, что использует i2p в стране Х, но допустим они все используют иностранные VPN. И нужно узнать хост зная имя i2p домена.
            +1
            Если вы держите веб-сайт, то задача спецслужбы заколючается в определении I2P адреса вашего маршутизатора, к которому прицеплен ваш сайт. Для этого нужно проследить маршрут какого нибудь из ваших входящих туннелей, который знаете только вы, как создатель этого тоннеля. Участники же знают только адреса следующих в тоннеле узлов. Посколько туннели как правило бывают в 3 узла, то достаточно придти в гости к этим 3 участникам. Проблема только в том, что эти узлы скорее всего окажутся в разных странах. А вот что все они могут принадлежать одному владельцу (спецслужбе) это запросто.
              0
              Спасибо, ясно, я не понимал, что рутер сервера определяет путь. Рутер сервера знает IP узлов маршрута? IP всех рутеров сети I2P публичны?
                0
                IP всех маршутизаторов публичны, более того текущий список можно скачать с ряда ftp-серверов.
                Роутер сервера в принципе может узнать IP адресов всех узлов созданного им тоннеля, но на самом деле ему это не нужно — он формирует лишь цепочку I2P адресов, входящих в тоннель, и отсылает сообщение первому из них через какой нибудь свой исходящий тоннель.
                В реальности IP адреса требуется знать только для пересылки сообщений между тоннелями.
                  0
                  Это как курица и яйцо? Что бы установить входящий тунель, нужен сначала исходящий тунель?

                  Вот я броузере ввожу forum.i2p, мой рутер должен как то сообщить рутеру сайта forum.i2p, что мне нужен тунель. Я что, это запрос отправляют всем рутерам сети, а запрос может разшифровать только forum.i2p?

                  Спасибо, я неделю назад, хотел разобраться, и понял, что нечего не понятно.
                    0
                    Наоборот для построения исходящего тоннеля нужен входящий, потому что иначе нельзя будет узнать результат создания тоннеля.
                    На самом деле запросы на создание тоннелей можно посылать и непосрдественно, но чтобы не заморачиваться ввели понятие «нулевых тоннелей», который начинаются и заканчиваются на своем маршутизаторе и создаются автоматически при страрте. Вот через них и создают первые тоннели.

                    Когда вы вводите адрес то сначала маршутизатор найдет по вашему адресу 32-х байтный хэш I2P адреса вашего сайта. Теперь имея это число вам нужно найти его какой нибудь входящий тоннель, запросив для этого его LeaseSet. Для этого вы выбираете какой нибудь достаточно, как вы думаете хороший, маршутизатор и посылаете туда запрос с этим адресом. Тут возможно 3 варианта:
                    1. Маршутизатор вернул вам LeaseSet
                    2. Маршутизатор сказал вам что не знает такого и возвращает список других маршутизаторов, которые по его мнению знают
                    3. Ничего вообще не отвечает

                    В варианте 2 пытаемся послать запрос тем маршутизатором, которые сказали. В варианте 3 повторям попытку используя другие тоннели, и, возможно, другой маршутизатор.
                    Когда вы получили нужный вам тоннель, вы отсылаете и шифруете сообщение для маршутизатора ключем, указанным в LeaseSet-е с точкой назначения I2P адресом нужного вам сайта.

                      0
                      То есть, я у всех подряд рутеров спрашиваю — не имеет ли он тунель на нужный мне сайт?

                      Например forum.i2p придумал несколько маршрутов и выгрузил на несколько рутеров.
                      Я запросил маршрут к forum.i2p у случайного рутера и мне повезло и он мне дал маршрут к forum.i2p, который forum.i2p туда выложил?

                      Если, я правильно понял, то этот случайный рутер знает, он выдал маршруи к forum.i2p или хотябы к чему то типа sha256(«forum.i2p»)?
                        0
                        LeaseSet всегда одинаковый. Маршутизатор просто держат компии и синхронизируют их.
                        Все маршруты объединены в один LeaseSet
                          0
                          forum.i2p формирует LeaseSet сам, выбирая из списка входящих тоннелей какие считает нужным. Затем он рассылает его нескольким маршутизаторам, а те передают дальше друг друга.
                          Что будет если попытаться себя за кого то другого, я, честно говоря, не знаю. Самому интересно. Возможно это у них дыра.
                            0
                            LeaseSet это все множество маршрутов. Маршрут это публичная открытая информация, которую может частично декодировать каждый рутер в маршруте, для хранения маршрутов используется децентрализированая база. (кусочек базы в каждом рутере)

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

                            Поэтому если я случайно подключусь к рутеру спецслужбы и запрошу маршруты, то среди тысячи маршрутов будет forum.i2p и они будут знать, что возможно один из 1000 маршрутов, что я скачал был тот, что меня реально интресует. + они знаю точку входа в каждый маршрут и, если я подключусь к первому рутеру маршрута, то они смогут отсечь 99% маршрутов.
                              +1
                              LeaseSet это множество тоннелей, ведущих к данной точке назначения. Для одного адреса LeaseSet всегда одинков, если в сети появится другой LeaseSet с тем же адресом, то правильным будет считаться более поздний.

                              Вы запрашиваете LeaseSet через тоннель, и если тот маршутизатор, который вы запрашиваете, окажется принадлежащими спецслужбам, то единственно что они могут узнать что некто интересуется этим адресом, а кто именно они не знают, потому как не знают, откуда идет ваш исходящий тоннель.
                            0
                            Для этого вы выбираете какой нибудь достаточно, как вы думаете хороший, маршутизатор и посылаете туда запрос с этим адресом.
                            Напрямую или через цепочку?
                              0
                              Запрос LeaseSet-а только через тоннель, иначе быстро засекут куда ходите.
                              Запрос другого маршутизатора можно и напрямую.
                  0
                  «Чеснок». Передача сообщений или последовательности между двумя кончеными узлами произвольным маршрутом и тоннелями


                  После этой фразы дальше читать стало гораздо веселее!
                    0
                    Спасибо, исправил.
                      0
                      Там дальше ещё много забавного; «оригинальное незашифрованное сообщение должно быть последовательно расшифровано перед его отправкой», например.
                        0
                        Это звучит забавно, но это именно так. Незашифрованное сообщение следует расшифровать.
                          +2
                          Алгоритмы шифрования таковы: есть две функции, Encrypt и Decrypt. Они обладают свойством: Encrypt(Decrypt(A)) = A и Decrypt(Encrypt(B)) = B. Из этого свойства следует, что вообще-то неважно, какая из них собственно «шифрует» а вторая — «расшифровывает», важно, что они работают в паре: если шифровали первой, расшифровывать второй, и наоборот, если шифровали второй, расшифровывать первой. Но для определённости всё равно одну из них называют Encrypt, другую Decrypt.

                          Это используется не только в i2p. Например, известный алгоритм 3DES (Triple DES) на самом деле есть трижды применённый DES по схеме EDE (на каждом этапе — свой подключ). Т.е. шифруем с помощью функции DES Encrypt первым подключем, потом полученное шифруем функцией DES Decrypt со вторым ключем и потом полученное наконец шифруем функцией DES Encrypt с третьим ключом, а результат — есть результат шифрования 3DES. Для расшифровки, соответственно, DED с теми же ключами. Поскольку все ключи разные и независимые, в целом схема в три раза сильнее DES — 168 бит против 56.
                        +1
                        Исходный код проекта в текущем состоянии располагается на гитхабе.
                        Вы не сравнивали его с i2pcpp (на Гитхабе и оригинал в i2p)?
                          0
                          Когда только начинал свой проект первым делом посмотрел на них. Там еще очень многое было не сделано: на тот момент не было даже туннелей. Сейчас они из добавили, но пока лишь транзитные.
                          В целом же у меня несколько иное видение по поводу развития проекта чем у них.
                          0
                          А у вас на гитхабе всё выложено?

                          Там в некоторых файлах Log.h инклудится, но я что-то его не вижу в репозитории.

                          И ещё, где точка входа а-ля main.cpp?
                            0
                            Спасибо что обратили на это внимание.
                            Log.h и Queue.h сейчас выложу.
                            Правильные main и Makefile еще не сделаны.
                              +1
                              Добавил все пропущенные файлы и обновил устаревшие.
                              Положил временный Makefile.
                              Теперь все должно собираться.
                              boost и crypto++ установите сами из репозитория вашего линукса
                                0
                                Для FreeBSD это порты devel/boost-all и security/cryptopp
                              0
                              Читал статью и не мог отделаться от выстраивания аналогий с соответствующей частью сети Tor. В Tor для обслуживания сайтов появляется две новых роли: introduction points и rendezvous points. Никак не могу взять в толк, кто в I2P аналог introduction point, а кто rendezvous point.
                                0
                                В I2P есть понятие floodfill-ов, это такие узлы которые обладают достаточно полной информации о сети, и, кроме того, берут на себя обязательства сообщать всю новую информацию другим floodfill-ам. Фактические это некие «справочники» сети, сообщающие любому желающему как обратиться к тому или иному узлу. Обычные маршутизаторы занимаются только построением тоннелей и пересылкой через них данных.

                              Only users with full accounts can post comments. Log in, please.