Баги выявляются и постепенно решаются силами сообщества. Проект не связан с какой-либо конторой, поэтому всё двигается не так быстро, как некоторым хочется. Однако, недавно видел информацию, что один из двух ведущих разработчиков тесно работает с Matrix (мессенджер) для интеграции в него работы p2p.
Ожидается релиз Yggdrasil 0.4, в котором планируется решение убивающих сеть "сетевых штормов". Об этой проблеме известно уже более полугода. В настоящий момент временным решением является вручную смайненный ключ подписи некоего узла энтузиаста, который всегда в сети и держит корень на себе.
Всё верно, в Yggdrasil присутствует DHT. В статье вопрос несколько упрощен для простоты восприятия не специализированного читателя. Насколько мне известно, DHT помимо координат содержит ключ и адрес узла. На вопрос "кто хранит маршрут" ответить навскидку не могу, чтобы не получилось ошибочно. Это требует разбирательства. Попробуйте посетить чаты сообщества (telegram, xmpp, matrix, irc). Возможно, там найдется человек, который ответит. Сам склоняюсь к тому, что маршрут хранится на конечных узлах сообщения, т.е. у конечных пользователей.
Я против повальных выходных прокси. А если кто-то их ставит — пусть будет готов к юридической ответственности и тд и тп. Внутрисетевая активность Yggdrasil подразумевает прямое взаимодействие двух адресов: пользователя и сервера, к которому он обращается. Сервер будет видеть Yggdrasil-адрес пользователя, а не промежуточных узлов. Поэтому в плане ответственности за активность здесь всё более-менее прозрачно.
Про кнопочки и интерфейсы: на смартфонах это уже реализовано. Смотрите гит-репозиторий.
Целью Tor является анонимность. Никакого удобства и настоящей децентрализации в Tor-е нет. Yggdrasil же обеспечивает приватность (вся информация зашифрована), но не обеспечивает анонимность (т.к. найти владельца адреса достаточно легко: ближайший к нему пир наверняка знает его реальное местоположение).
Это одно из основных использований Yggdrasil сегодня: подключаемся к публичному пиру по его "белому" адресу через Интернет, и получаем устойчивое соединение со своим белым внутрисетевым IPv6-адресом Yggdrasil. Так играют в Minecraft и на USB-модемах поднимают свои общедоступные веб-сервисы (небольшие).
Были мысли упомянуть "шину" и "кольцо", но воздержался во имя защиты статьи от перегрузки информацией, не актуальной сегодня, либо же просто мешающей среднему пользователю уловить суть сабжа. Но "кольцо", конечно, мощь! :)
Несколько другая ситуация, на мой взгляд: вы в своих же интересах будете подцепляться к нескольким соседским узлам сети, тем самым обеспечивая собственную бесперебойность и вместе с тем — общую связность сети. Вы отвечаете за свой узел и не зависите от того, чей узел почему-то упадет, потому что вокруг десятки таких же как и вы заинтересованных в работоспособности собственного узла для личного выхода в сеть.
Интернет входит в квартиру по всем возможным линкам, которые ведут хотя бы к соседям, а тех соседей в следующий дом и так далее. Меш в описанном виде — некоторый упорядоченный самоорганизующийся хаос. И в этом его красота, как по мне :)
Устоявшееся понимение IP говорит нам, что должен быть шлюз по умолчанию и т.п. В случае "народного меша везде и во всем" любой Wi-Fi и провод, т.е. любой физический линк с другими устройствами является вероятным маршрутом выхода в глобальную сеть. На то она и ячеистая топология, когда каждый участник сети также выступает и роутером.
Ага, есть такое впечатление. Но важно понимать, что в виде звезды представляется дерево маршрутизации, а не реальные соединения участников. У любого узла сети может быть десяток прямых линков с другими, по которым будет ходить трафик, но координаты от этого не изменятся. Если пропадет один "центральный узел", координаты быстро перестроятся на новом "корне". Как видите, топологии "звезда" здесь нет, нет единой точки отказа в виде центрального узла, через который идет весь трафик.
Кустарный способ для малых проектов собственного использования:
На основном сервере раз в сутки создается архив с критической информацией, шифруется GPG. Через Nginx файл доступен через веб по некоему URL а-ля /secret-folder/ha/br/backup$(date -d "$date -1 days" +"%F").tar.gz.gpg с допуском только с определенным user-agent. Также используется нестандартное значение вроде "itsmebaby".
На резервной VPS с бэкапами не нужно хранить какие-либо ssh-ключи и прочее, а всего лишь положить простенький bash-скрипт в cron.daily. Доступ к скаченным бэкапам можно открыть через FTP или вовсе через Nginx, позволяя скачать в обычном браузере.
Использование GPG лишает схему критических уязвимостей утечки.
Существует форк Popura от российского энтузиаста. Он реализовал встроенный meshname-DNS (наверное, напишу статью про эту систему, основанную на кодировании IPv6 в Base32), а также автопиринг — автоматическое добавление публичных узлов. Сей персонаж под ником zhoreeq обитает в ILITA IRC, как я неоднократно замечал, поэтому, если интересно, заглядывайте (доступ к ирке через Yggdrasil и I2P).
Благо, Yggdrasil — свободный проект, поэтому GUI и всё остальное может предлагать и запиливать любой желающий. Ждём развития. Я конечно всеми руками за веб-интерфейс, т.к. это позволит удобно админить Ygg на удаленных серверах.
Вы будто мстите мне, осыпая занятной терминологией :) При написании статьи я имел ввиду связность конкретного узла.
Однако можно разобрать примерную схему против "хоть кого-то": предварительно сканируем сеть, записываем все обнаруженные IPv6 (которых сейчас в сети ~1500), затем запускаем майнер, и проверяем получаемые адреса на коллизию. Будет медленнее, чем с коротким паттерном поиска, но намного эффективнее пингования каждого полученного адреса.
Не думал, что такие дебри будут интересны читателям!
Маршрутизация в Yggdrasil происходит по DHT-координатам, которые отталкиваются от реальной топологии, а корень этого DHT-дерева определяется по некоторому критерию ключа подписи EdDSA. Т.е. ключи, образующие IPv6, в логике маршрутизации практически не участвуют.
Если тема интересна, могу оформить всё в небольшую статью.
P.S. Когда ковырялся в дебрях кода Yggdrasil, заметил, что NodeID там называется сырой хеш SHA512 от ключа. От него потом образуется IPv6.
Что мне мешает провести сессию с каким-то узлом и присвоить себе его же адрес
В вашем вопросе вопиющее непонимание невозможности выведения закрытого ключа из открытого, который вы получаете в ходе сессии с участником сети. Вы меня троллите?
orignal, об этом, как я понял, и речь. Дескать GUI всем подавай, а демоны пусть у сатанистов на фоне бегают. (с) kai3341, я как раз в процессе написания большой статьи про Yggdrasil (на твое право описывать шишки не претендую:)
Про Флибусту ты ошибаешься, глянь тут:
http://[300:529f:150c:eafe::1]Я сам флибусту последний год только через Yggdrasil открываю ;)
Баги выявляются и постепенно решаются силами сообщества. Проект не связан с какой-либо конторой, поэтому всё двигается не так быстро, как некоторым хочется. Однако, недавно видел информацию, что один из двух ведущих разработчиков тесно работает с Matrix (мессенджер) для интеграции в него работы p2p.
Ожидается релиз Yggdrasil 0.4, в котором планируется решение убивающих сеть "сетевых штормов". Об этой проблеме известно уже более полугода. В настоящий момент временным решением является вручную смайненный ключ подписи некоего узла энтузиаста, который всегда в сети и держит корень на себе.
Всё верно, в Yggdrasil присутствует DHT. В статье вопрос несколько упрощен для простоты восприятия не специализированного читателя. Насколько мне известно, DHT помимо координат содержит ключ и адрес узла. На вопрос "кто хранит маршрут" ответить навскидку не могу, чтобы не получилось ошибочно. Это требует разбирательства. Попробуйте посетить чаты сообщества (telegram, xmpp, matrix, irc). Возможно, там найдется человек, который ответит. Сам склоняюсь к тому, что маршрут хранится на конечных узлах сообщения, т.е. у конечных пользователей.
Я против повальных выходных прокси. А если кто-то их ставит — пусть будет готов к юридической ответственности и тд и тп. Внутрисетевая активность Yggdrasil подразумевает прямое взаимодействие двух адресов: пользователя и сервера, к которому он обращается. Сервер будет видеть Yggdrasil-адрес пользователя, а не промежуточных узлов. Поэтому в плане ответственности за активность здесь всё более-менее прозрачно.
Про кнопочки и интерфейсы: на смартфонах это уже реализовано. Смотрите гит-репозиторий.
Целью Tor является анонимность. Никакого удобства и настоящей децентрализации в Tor-е нет. Yggdrasil же обеспечивает приватность (вся информация зашифрована), но не обеспечивает анонимность (т.к. найти владельца адреса достаточно легко: ближайший к нему пир наверняка знает его реальное местоположение).
Это одно из основных использований Yggdrasil сегодня: подключаемся к публичному пиру по его "белому" адресу через Интернет, и получаем устойчивое соединение со своим белым внутрисетевым IPv6-адресом Yggdrasil. Так играют в Minecraft и на USB-модемах поднимают свои общедоступные веб-сервисы (небольшие).
Были мысли упомянуть "шину" и "кольцо", но воздержался во имя защиты статьи от перегрузки информацией, не актуальной сегодня, либо же просто мешающей среднему пользователю уловить суть сабжа. Но "кольцо", конечно, мощь! :)
Несколько другая ситуация, на мой взгляд: вы в своих же интересах будете подцепляться к нескольким соседским узлам сети, тем самым обеспечивая собственную бесперебойность и вместе с тем — общую связность сети. Вы отвечаете за свой узел и не зависите от того, чей узел почему-то упадет, потому что вокруг десятки таких же как и вы заинтересованных в работоспособности собственного узла для личного выхода в сеть.
Я и СОРМ домой поставлю, всё во славу Фемиды!
Интернет входит в квартиру по всем возможным линкам, которые ведут хотя бы к соседям, а тех соседей в следующий дом и так далее. Меш в описанном виде — некоторый упорядоченный самоорганизующийся хаос. И в этом его красота, как по мне :)
Устоявшееся понимение IP говорит нам, что должен быть шлюз по умолчанию и т.п. В случае "народного меша везде и во всем" любой Wi-Fi и провод, т.е. любой физический линк с другими устройствами является вероятным маршрутом выхода в глобальную сеть. На то она и ячеистая топология, когда каждый участник сети также выступает и роутером.
Ага, есть такое впечатление. Но важно понимать, что в виде звезды представляется дерево маршрутизации, а не реальные соединения участников. У любого узла сети может быть десяток прямых линков с другими, по которым будет ходить трафик, но координаты от этого не изменятся. Если пропадет один "центральный узел", координаты быстро перестроятся на новом "корне". Как видите, топологии "звезда" здесь нет, нет единой точки отказа в виде центрального узла, через который идет весь трафик.
Кустарный способ для малых проектов собственного использования:
На основном сервере раз в сутки создается архив с критической информацией, шифруется GPG. Через Nginx файл доступен через веб по некоему URL а-ля /secret-folder/ha/br/backup$(date -d "$date -1 days" +"%F").tar.gz.gpg с допуском только с определенным user-agent. Также используется нестандартное значение вроде "itsmebaby".
На резервной VPS с бэкапами не нужно хранить какие-либо ssh-ключи и прочее, а всего лишь положить простенький bash-скрипт в cron.daily. Доступ к скаченным бэкапам можно открыть через FTP или вовсе через Nginx, позволяя скачать в обычном браузере.
Использование GPG лишает схему критических уязвимостей утечки.
Существует форк Popura от российского энтузиаста. Он реализовал встроенный meshname-DNS (наверное, напишу статью про эту систему, основанную на кодировании IPv6 в Base32), а также автопиринг — автоматическое добавление публичных узлов. Сей персонаж под ником zhoreeq обитает в ILITA IRC, как я неоднократно замечал, поэтому, если интересно, заглядывайте (доступ к ирке через Yggdrasil и I2P).
Благо, Yggdrasil — свободный проект, поэтому GUI и всё остальное может предлагать и запиливать любой желающий. Ждём развития. Я конечно всеми руками за веб-интерфейс, т.к. это позволит удобно админить Ygg на удаленных серверах.
Спуфинг — уместный термин. Статья с подобным заголовком и теоритическим разбором угрозы была написана еще минувшим летом на howto.ygg — внутрисетевой wiki Yggdrasil.
http://[300:529f:150c:eafe::6]/doku.php?id=yggdrasil:spoofing_theory
Вы будто мстите мне, осыпая занятной терминологией :) При написании статьи я имел ввиду связность конкретного узла.
Однако можно разобрать примерную схему против "хоть кого-то": предварительно сканируем сеть, записываем все обнаруженные IPv6 (которых сейчас в сети ~1500), затем запускаем майнер, и проверяем получаемые адреса на коллизию. Будет медленнее, чем с коротким паттерном поиска, но намного эффективнее пингования каждого полученного адреса.
Да, в силу того, что IPv6 является лишь частью NodeID. Как раз эта вероятность описывается, как угроза.
Не думал, что такие дебри будут интересны читателям!
Маршрутизация в Yggdrasil происходит по DHT-координатам, которые отталкиваются от реальной топологии, а корень этого DHT-дерева определяется по некоторому критерию ключа подписи EdDSA. Т.е. ключи, образующие IPv6, в логике маршрутизации практически не участвуют.
Если тема интересна, могу оформить всё в небольшую статью.
P.S. Когда ковырялся в дебрях кода Yggdrasil, заметил, что NodeID там называется сырой хеш SHA512 от ключа. От него потом образуется IPv6.
В вашем вопросе вопиющее непонимание невозможности выведения закрытого ключа из открытого, который вы получаете в ходе сессии с участником сети. Вы меня троллите?
Клирнет надо тормозить чаще и больше, а то все расслабились. Что касается DPI в I2P: https://youtu.be/ItkdvFocCQs?t=1112
orignal, об этом, как я понял, и речь. Дескать GUI всем подавай, а демоны пусть у сатанистов на фоне бегают. (с)
kai3341, я как раз в процессе написания большой статьи про Yggdrasil (на твое право описывать шишки не претендую:)