Comments 12
Проект интересный, но как то не хватает технической части.
По-моему заголовок не соответствует содержанию: читая «Построение собственной коммуникационной сети» я предполагаю увидеть внутри что-то именно про сеть, т.е. какую-то базовую вещь, которой потом сможет пользоваться остальное ПО, т.е. в большинстве случаев это IP или Ethernet сеть, возможно какая-то другая но тоже базовая — которой потом сможет пользоваться какая-то программа которая ничего не знает про I2P. Тут получается очень специализированная вещь только для программы которая будет специально под этот протокол написана.
По сути:
Как я понял — основная причина построения сети — повышение стабильности за счет раннего обнаружения отказов промежуточных узлов. А чем эта система лучше, чем отправка сообщение alive при tcp-соединениях через socks-прокси для I2P или каких-то пингов на уровне собственного приложения поверх обычной I2P сети, без использования специальных серверов?
По опыту использования I2P у меня сложилось мнение о таких неудобствах:
1. Высокая латентность
2. Ограниченное использование существующего ПО — как я помню там или соединения точка-точка через socks-прокси или http через http-прокси, либо уже что-то специальное.
Отчасти можно побудить пингами и перестроением тоннелей, хотя я с таким на практике не сталкивался — спокойно бродил по внутренним сайтам без каких-то явно больших задержек.
Что хочется:
Вот хорошо бы решить эту задачу — т.е. построение сети общего назначения: собственный VPN (IP/Ethernet) или какая-то более широкая IP-сеть. Чтобы участники этой сети могли просто подключить в компьютер дополнительный сетевой адаптер и например там между собой смогли бы общаться Jabber-сервера по обычному протоколу, Seafile-хранилища, можно было бы стандартными средствами попинговать узел чтобы понять жив ли он или например выходить в интернет через какой-то шлюз без заворачивания трафика на http-прокси а просто обычной настройкой маршрутизации или подключением к какому-то VPN-серверу опять же обычными средствами.
При этом реализация на стороне клиента обеспечивала бы хождение трафика P2P без участия центральных серверов, а центральные сервера занимались бы распределением IP-адресов и указанием соответствия. Условно что сейчас IP 1.2.3.4 соответствует I2P адресу abcd и дальше обмен трафиком между ними идет уже напрямую.
По сути:
Как я понял — основная причина построения сети — повышение стабильности за счет раннего обнаружения отказов промежуточных узлов. А чем эта система лучше, чем отправка сообщение alive при tcp-соединениях через socks-прокси для I2P или каких-то пингов на уровне собственного приложения поверх обычной I2P сети, без использования специальных серверов?
По опыту использования I2P у меня сложилось мнение о таких неудобствах:
1. Высокая латентность
2. Ограниченное использование существующего ПО — как я помню там или соединения точка-точка через socks-прокси или http через http-прокси, либо уже что-то специальное.
Отчасти можно побудить пингами и перестроением тоннелей, хотя я с таким на практике не сталкивался — спокойно бродил по внутренним сайтам без каких-то явно больших задержек.
Что хочется:
Вот хорошо бы решить эту задачу — т.е. построение сети общего назначения: собственный VPN (IP/Ethernet) или какая-то более широкая IP-сеть. Чтобы участники этой сети могли просто подключить в компьютер дополнительный сетевой адаптер и например там между собой смогли бы общаться Jabber-сервера по обычному протоколу, Seafile-хранилища, можно было бы стандартными средствами попинговать узел чтобы понять жив ли он или например выходить в интернет через какой-то шлюз без заворачивания трафика на http-прокси а просто обычной настройкой маршрутизации или подключением к какому-то VPN-серверу опять же обычными средствами.
При этом реализация на стороне клиента обеспечивала бы хождение трафика P2P без участия центральных серверов, а центральные сервера занимались бы распределением IP-адресов и указанием соответствия. Условно что сейчас IP 1.2.3.4 соответствует I2P адресу abcd и дальше обмен трафиком между ними идет уже напрямую.
>Условно что сейчас IP 1.2.3.4 соответствует I2P адресу abcd и дальше обмен трафиком между ними идет уже напрямую.
И прощай вся анонимность.
И прощай вся анонимность.
>Условно что сейчас IP 1.2.3.4 соответствует I2P адресу abcd и дальше обмен трафиком между ними идет уже напрямую
Причем делается достаточно просто.
1. При настройке роутера указываешь блок серых адресов, на которые будут мапиться i2p адреса. Один из этих адресов — адрес роутера.
2. Роутер поднимает интерфейс с адресом из этого блока.
3. Роуер поднимает DNS сервер, который резолвит *.i2p в адреса из серого блока. С каким нибудь мелким ttl.
После этого начинает работать весь софт, и серверный и клиентский, который вообше ни сном ни духом о всяких прокси и соксах.
Осталось сесть и написать. :)
Причем делается достаточно просто.
1. При настройке роутера указываешь блок серых адресов, на которые будут мапиться i2p адреса. Один из этих адресов — адрес роутера.
2. Роутер поднимает интерфейс с адресом из этого блока.
3. Роуер поднимает DNS сервер, который резолвит *.i2p в адреса из серого блока. С каким нибудь мелким ttl.
После этого начинает работать весь софт, и серверный и клиентский, который вообше ни сном ни духом о всяких прокси и соксах.
Осталось сесть и написать. :)
>Как я понял — основная причина построения сети — повышение стабильности за счет раннего обнаружения отказов промежуточных узлов.
Более важная причина это заведомая полнота базы, на которых наши клиенты объявляют свои LeaseSet-ы, тем самым гарантируя, что если LeaseSet опубликован, то он будет найден другим клиентом всегда.
>А чем эта система лучше, чем отправка сообщение alive при tcp-соединениях через socks-прокси для I2P или каких-то пингов на уровне собственного приложения поверх обычной I2P сети, без использования специальных серверов?
Тоннели работают только в одну сторону, потому вы должны пинговать пару тоннелей, а если пинг не вернулся, то непонятно какой из двух помер.
Кроме того, введение одного заведомо надежного узла снижает вероятность отказа тоннеля на треть.
Более важная причина это заведомая полнота базы, на которых наши клиенты объявляют свои LeaseSet-ы, тем самым гарантируя, что если LeaseSet опубликован, то он будет найден другим клиентом всегда.
>А чем эта система лучше, чем отправка сообщение alive при tcp-соединениях через socks-прокси для I2P или каких-то пингов на уровне собственного приложения поверх обычной I2P сети, без использования специальных серверов?
Тоннели работают только в одну сторону, потому вы должны пинговать пару тоннелей, а если пинг не вернулся, то непонятно какой из двух помер.
Кроме того, введение одного заведомо надежного узла снижает вероятность отказа тоннеля на треть.
Более важная причина это заведомая полнота базы, на которых наши клиенты объявляют свои LeaseSet-ы, тем самым гарантируя, что если LeaseSet опубликован, то он будет найден другим клиентом всегда.
Если я правильно понял LeaseSet это условно информация через какие маршрутизаторы можно подключиться к тому или иному I2P-адресу.
Т.е. условно — вы предлагаете централизованная база маршрутов, чтобы быстрее находить путь подключения?
Мне кажется это стоит отдельно проверять на снижение уязвимостей — не зря же сделан путь в несколько хопов с намеренным сокрытием маршрута следования и невозможностью определить конечного получателя (т.е. кто этот узел — адресат или тоже промежуточный узел).
Если будет центральная база адресов может появиться соответствие — как найти конечный узел и возможно зная это можно понять на каком IP-адресе он работает.
Это общие соображения — I2P пробовал относительно давно и недолго, т.к. нормальное ПО не работает, а специализированным общаться не с кем. Поясните где неправ.
Тоннели работают только в одну сторону, потому вы должны пинговать пару тоннелей, а если пинг не вернулся, то непонятно какой из двух помер.
Ну и нормально если любой из туннелей упал — перестроить оба. Это же не происходит ежеминутно чтобы требовало каких-то больших оптимизаций по снижению накладных расходов трафика. А по времени — они могут перестраиваться параллельно и времени уйдет столько же сколько на перестройку одного туннеля.
Кроме того, введение одного заведомо надежного узла снижает вероятность отказа тоннеля на треть.
Ну и степень анонимности снижается настолько же — этого эффекта (даже лучше) можно добиться если в настройках туннеля поставить на 1 хоп меньше.
Насчет LeaseSet-а в целом правильно — это текущий набор входящих тоннелей.
Маршруты могут быть какие угодно, тут идея иная.
Допустим вы хотите опубликовать LeaseSet вашего адреса, вы должен это делать на «ближайщем» к вам (в смысле DHT) floodfill-е. Сделали.
Теперь ваш товарищ хочет к вам обратиться и он станет искать ваш LeaseSet тоже на ближайщем вам floodfill-е. Но может оказаться так что эти floodfill-ы у вас и у него разные потому что в этот момент у вас и у него него разное содержимое netDb.
Мы же собираемся публиковать на своих серверах.
>Ну и нормально если любой из туннелей упал — перестроить оба. Это же не происходит ежеминутно чтобы требовало каких-то больших оптимизаций по снижению накладных расходов трафика. А по времени — они могут перестраиваться параллельно и времени уйдет столько же сколько на перестройку одного туннеля.
Именно так сейчас и делается. Но постройка тоннеля — удовольствие дорогое. Кроме того у многих маршрутизаторов стоит ограничение на число транзитных тоннелей. В итоге получается что висит масса неиспользумых тоннелей, потому что время жизни тоннеля строго 10 минут.
>Ну и степень анонимности снижается настолько же — этого эффекта (даже лучше) можно добиться если в настройках туннеля поставить на 1 хоп меньше.
Так наш сервер может располагаться в произвольном месте тоннеля, так что это не равносильно уменьшению на один хоп.
Кстати в некоторых запущенных случаях (когда клиент сидит за нат-ом и закрыто почти все) придется удлинять тоннели на один хоп, делая наш сервер первым.
Маршруты могут быть какие угодно, тут идея иная.
Допустим вы хотите опубликовать LeaseSet вашего адреса, вы должен это делать на «ближайщем» к вам (в смысле DHT) floodfill-е. Сделали.
Теперь ваш товарищ хочет к вам обратиться и он станет искать ваш LeaseSet тоже на ближайщем вам floodfill-е. Но может оказаться так что эти floodfill-ы у вас и у него разные потому что в этот момент у вас и у него него разное содержимое netDb.
Мы же собираемся публиковать на своих серверах.
>Ну и нормально если любой из туннелей упал — перестроить оба. Это же не происходит ежеминутно чтобы требовало каких-то больших оптимизаций по снижению накладных расходов трафика. А по времени — они могут перестраиваться параллельно и времени уйдет столько же сколько на перестройку одного туннеля.
Именно так сейчас и делается. Но постройка тоннеля — удовольствие дорогое. Кроме того у многих маршрутизаторов стоит ограничение на число транзитных тоннелей. В итоге получается что висит масса неиспользумых тоннелей, потому что время жизни тоннеля строго 10 минут.
>Ну и степень анонимности снижается настолько же — этого эффекта (даже лучше) можно добиться если в настройках туннеля поставить на 1 хоп меньше.
Так наш сервер может располагаться в произвольном месте тоннеля, так что это не равносильно уменьшению на один хоп.
Кстати в некоторых запущенных случаях (когда клиент сидит за нат-ом и закрыто почти все) придется удлинять тоннели на один хоп, делая наш сервер первым.
Лучше бы вы написали, что ваш реализация I2P на C++ уже работает =) таким образом, может быть еще разработчики бы подтянулись
Sign up to leave a comment.
Построение собственной коммуникационной сети поверх I2P