Pull to refresh

Comments 34

не совсем понимаю цели проекта, spanning tree работает на высокоскоростных hw switches, поэтому задержки в передаче пакетов минимальны, если делать нечто подобное через host, тем более, если правильно понимаю поверх tcp, случайно выбранные «ip v6 псевдо адреса» на интерфейсах host приведут к большим непредсказуемым задержкам в доставке пакетов, далее не понимаю причин использования здесь ip v6, если настоящее routing делается совсем по другому ip адресу, вполне можно был выбрать свое собственное адресное пространство, ни как не связанное с ip, разве не так?
ps
посмотрел сайт Tapestry (DHT), все равно не понимаю, как именно достигается «маршрутизация с упором на эффективность и минимизацию задержки сообщений»

ipv6 используется чтобы существующий софт мог без проблем работать через сеть

что именно, какой существующий софт (разве это все не с «0» пишется), если протокол работает поверх tcp, routing использует совсем другой ip адрес именно зависящий от конфигурации host, если правильно понимаю сгенеренные ip v6 адреса вообще видны только на host, почему бы не использовать в этой связи для идентификаии host в составе Yggdrasil любой другой уникальный собственный id, понимаю, что этот вопрос возможно не к вам, тем не менее буду признателен за объяснение

Чтобы использовать свои пространства адресов, как это делается в Tor и I2P, необходимо все запросы пользователя направлять на локальный прокси, который обработает запрос. Фишка Yggdrasil в том, что выход в сеть выходит через виртуальный сетевой интерфейс (WireGuard, принцип работы VPN), которому автоматически присваивается нужный IPv6-адрес и ваша операционная система понимает куда нужно маршрутизировать запросы на 200::/7 без всяких дополнительных настроек прокси. Очень удобно. Чтобы лучше понять - просто попробуйте: установили Yggdrasil, прописали публичные пиры для связи с глобальным сегментом сети, затем открываете веб-браузер и без всяких настроек открываете IPv6-адреса из диапазона Ygg. Соответственно все серверные (и клиентские) конфиги прикладных программ также не нуждаются в перенаправлении на прокси и прочих нечитабельных нагромождениях: просто указываете в конфиге nginx (или чего-то еще) ваш IPv6-адрес Yggdrasil и считайте, что ваш веб-ресурс уже в сети!

Пользовательская маршрутизация внутри Yggdrasil также происходит по IPv6, которые клиент сети обрабатывает внутри себя, ориентируясь на криптографические ключи узлов и прочую инкапсулированную от пользователя логику.

Можете задать уточняющий вопрос, если мой ответ не является понятным или исчерпывающим. Возможно, я вас недопонял.

спасибо, кажется начинаю понимать, это sw работает на host типа relay на пользовательском уровне ip v6 адресов из url, в реальные ip адреса, которые двигают пакет через сеть обычным образом, правильно?
конфигурация чисто статическая,


ваша операционная система понимает куда нужно маршрутизировать запросы на 200::/7 без всяких дополнительных настроек прокси.

вероятно драйвер соответствующего созданного интерфейса,


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

Вы мыслите в верном направлении.

которые двигают пакет через сеть обычным образом

Тут однозначно сказать нельзя, потому что надо помнить про сквозное шифрование и прочее (свой протокол). Это высказывание верно также, как высказывание, что пакет сетей Tor и I2P идет от вас по сети обычным образом. Магии однозначно нет - идет обычным образом, но этот образ на более высоком уровне (программном) обеспечивается логикой клиента сети, отвечающего за маршрутизацию, шифрование и т.п.

Если поставите себе клиент сети, можете заглянуть в IRC для обсуждения и вопросов http://[324:71e:281a:9ed3::41]/, канал #howtoygg.

да понимаю, шифрование само собой, ну это уже другой уровень, сейчас пытаюсь понять, что это значит на сетевом (3) уровне

На сетевом уровне - передача трафика на IP-адрес публичного пира, к которому вы подключились, либо на локальный адрес, если работаете в локалке (где сеть Yggdrasil организуется автоматически через мультикаст).

да конечно, авторы в своих сообщениях на reddit акцентируют routing, пытаюсь понять есть ли рациональное зерно, шифрование это особая статья сейчас мне не слишком интересная
ps
когда-то работал под одной крышей с radia perlman, и ее мужа майка знал, вообще сетями долго занимался, так что кое-что еще помню про routing :)

Это конечно удобно, но оставляет всего 112 бит ключа для публичного адреса. Если кто-то захочет захватить адрес, ему нужно будет совершить перебор приватного ключа в объёме 112 бит, чтобы получить нужный публичный адрес. Это конечно много, но для ресурсов, которые есть у государств, вроде и нет (даже 160-битные ключи давно призывают менять на 256 и 512-битные).

Да, эта тема обсуждалась. Но пока что реальных прецедентов при всех попытках не было.

Рекомендую ознакомиться с термином "Выского адреса" - адреса с большим значением во втором байте: чем выше это значение - тем большее количество бит ключа используется в образовании IPv6. Старая статья про образование IPv6 в Yggdrasil, но понятие "Высокого адреса" актуально.

Майнер адресов.

Неважно. Несколько бит погоды не сделают.
Пока что сеть спасает статус «неуловимого джо», хотя если такие атаки будут практически использоваться, никто не запрещает сделать ещё один breaking change.

Ключи ed25519 и x25519, которые используются практически повсеместно составляют всего 256 бит (32 байта). Если вдруг появится фактическая возможность их конвеерного брутфорса, то у меня плохие новости для человечества в целом)) Насколько я знаю, вероятность подбора этих ключей в разумные сроки даже на самом превосходном железе пока что не заявлена.

Наглядный бытовой пример: чтобы получить ключ с лидирующими тридцатью семью нулями (нулевыми битами) нужно на домашнем железе затратить несколько минут, а иногда и часов. Остальные 14 байт после этих нулей составляют тело IPv6-адреса Yggdrasil. Очевидно, что энтропия 14 байт из тела адреса отлично усложняется изначальным количеством лидирующих нулей. По тестам энтузиастов и своим личным могу сказать, что каждый бит делает погоду. Сложность растет по экспоненте.

Для каких-либо проектов в сети Yggdrasil я рекомендую одну ночь помайнить высокий адрес, чтобы оставшийся свой век даже не думать, что кто-то будет пытаться брутфорсить.

Ключи ed25519 и x25519, которые используются практически повсеместно составляют всего 256 бит (32 байта)
А какая разница, если в адрес идёт только 112 бит? Можно сбрутить другой 256-битный ключ, у которого 112 бит адреса совпадает, и стать той самой нодой с нужным адресом?

Половину от такого ключа подобрать тоже сложно, но мысль в другом: чем выше ключ (чем выше второй байт IPv6-адреса) тем большее количество бит от ключа используется. Это является дополнительным фактором безопасности. В теории высокий адрес может использовать 90% (а в абсолютном вакууме и все 100%) от публичного ключа.

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

Если вы не совсем поняли при чем тут "высота" адреса и объем использованной информации от публичного ключа, посмотрите на иллюстрацию в этой статье, которая описывает алгоритм образования IPv6.

Прочитал внимательно, понял. Интересная идея. Атакующему нужно найти не любую коллизию на 112 битах, а редкую коллизию. Фактически, второй байт определяет, на сколько бит увеличивается перебираемый ключ. Например, второй байт = 0x20 — увеличивается на 32 бита, т.е. надо перебирать 144 бита уже, а не 112.

Причём для своего адреса намайнить коллизию намного проще, чем для атакующего. У него множитель сложности x2112, когда у абонента множитель x1

Абсолютно верно. Стоит отметить, что адрес с высотой в 32 бита (как в вашем примере с вторым байтом == 0x20) - даже на старом домашнем ПК находится за минуты, а вот дальнейший подбор коллизии такого адреса усложняется N-кратно, где N - очень и очень много.

4 дня майнил высокий адрес с параметром майнера «Start position for high addresses (14 by default) » = 32, как-то не выходит каменная чаша :(
скорость ~100 kH/s.
Или я неправильно понял этот параметр?

IPv6 представлен в шестнадцатеричном формате (hex).

14 - значение майнера по умолчанию, это шестнадцатеричное представление; в десятичной системе счисления это значение соответствует 20, то есть по умолчанию происходит поиск адресов более, чем с двадцатью лидирующими битами, установленными в 1.

Я упомянул 32 лидирующих бита, при этом имел ввиду десятичную систему счисления. 32 в десятичной - это 20 в шестнадцатеричной системе счисления. То есть для реализации описанного в комментарии выше, вам необходимо задать параметр 20, а не 32 :)

32 в шестнадцатеричном представлении - это 50 в десятичном, то есть в 2,5 раза больше, чем значение по умолчанию. Это значение вы безуспешно майнили 4 дня.

Зарядил майнинг адресов 0x20, посмотрим.
А есть данные какого-либо аудита ПО yggdrasil и alfis — а то поставил, а теперь думаю — кому для чего ворота открыл? :) (фаерволл на ipv6 поставил)
Зато удобно — свой статический IP без оглядки на NAT и серые провайдерские адреса, свое неотъемлемое доменное имя (пока ключи не уведут :) Немного напрягает зависимость от прописанных шлюзов, которые могут контролировать твой трафик, пусть и зашифрованный (или перестать работать)… или там динамически еще подтягиваются другие?

Исходный код упомянутых проектов открыт и по объему весьма скромный. При большом желании аудит можно провести самому (с базовым пониманием программирования, языков Go - для Yggdrasil и Rust - для Alfis). Домены Alfis необходимо каждый год перемайнивать, иначе они истекают - своеобразная защита от киберсквотинга, при этом всё бесплатно, а ненужные хозяину домены снова становятся доступны.

Зависимость от публичных пиров есть. Однако замечен интересный лайфхак: поставьте Yggdrasil на любой сервер с выделенным IP-адресом и опубликуйте его в списке публичных пиров. Каждый, кто подцепится к вашему пиру, автоматически обеспечит его связность с остальной сетью. Ну а сами подцепляйтесь только к своему пиру, в стабильности которого уверены.

Приветствую !

6 дней майнились 3 ip-адреса с высотой в 32 бита, нифига не минуты :))

Хотел уточнить по доступу - если я делаю пир на своей рабочей машине, могут ли нелокальные ноды, которые к нему законнектятся, получить доступ в корпоративные локальные сети, доступные для этой рабочей машины, или весь трафик на порт пира уходит ТОЛЬКО в сеть Ygg ? А то способности маршрутизации сервера Ygg нестандартные, не получится ли взлом по вектору INET -> Ygg peer -> Local net corp ? Напрягает фраза в howto "Все подключенные пиры будут считаться подключенными локально, будто они с вами в одной локальной сети. Учитывайте это при настройке безопасности."

Задал этот же вопрос в IRC, внятного ответа не получил, только совет закрыться фаерволлом от чужих IP. А мне нужна возможность доступа с любого IP, но так чтобы они не получили доступ во внутреннюю корпоративную сеть ...

Майнер SYG имеет по умолчанию функцию увеличения высоты искомых адресов: если нашелся один с высотой >= 32 бита, то следующий ищется с высотой выше предыдущего. Если вы не отключили auto-increase, то вполне возможно искать три адреса несколько суток, потому что второй адрес, например, был очень высокий, и чтобы сработало следующее нахождение - третий адрес должен быть еще выше.

Вот пример майнинга без увеличения высоты на двух слабеньких ядрах (4 адреса - меньше 10 минут).

Все подключенные пиры будут считаться подключенными локально, будто они с вами в одной локальной сети. Учитывайте это при настройке безопасности.

Под этими словами я подразумевал Yggdrasil-соединения, а под "локальной сетью" - исключительно прямую доступность узлов в рамках сети Yggdrasil.

Доступа в корпоративную сеть предприятия не будет, если говорим об обычном IPv4 или IPv6, который не относится к Yggdrasil, однако будет полный доступ (в меру ограничений файерволла) к машине в этой сети, на которой установлен Yggdrasil.

Если в вашей рабочей сети всего один узел с Yggdrasil, который адекватно настроен, он не опаснее обычного сервера в локальной сети, который имеет выделенный (белый) IPv4.

если я делаю пир на своей рабочей машине, могут ли нелокальные ноды, которые к нему законнектятся, получить доступ в корпоративные локальные сети, доступные для этой рабочей машины
Зависит от того, какие сервисы расположены на этой машине. Например, если там есть открытый прокси-сервер, он доступен из Ygg, а с него доступна корпоративная сеть. Если у вас включен RDP, злоумышленники из Ygg могут брутфорсить пароль, или дождаться какой-нибудь zero-day для любого другого сетевого сервиса Windows. Обычно рабочие машины не торчат наружу в inet, а прикрыты хотя бы NAT (в случае IPv6 — запрет входящих соединений на роутере, кроме специально открытых портов). Тут же вы создаёте канал прямо на рабочий компьютер в обход всех фаирволов.
Входящие соединения из обычного инет фильтруются фаерволлом… Из сети IPv6 (в том числе Ygg) тоже, тут проблем нет…
Опасаюсь именно внутренних возможностей маршрутизации сервера Ygg, который сдуру может направить трафик (пришедший на peer-порт Ygg) к внутренним адресам сети (тут iptables не спасет)…
который сдуру может направить трафик (пришедший на peer-порт Ygg) к внутренним адресам сети
Если даже как-то «отравить» таблицы маршрутизации, и роутер Ygg отправит пакет не пиру, а куда-то в локальную сеть, этот пакет всё равно будет зашифрован и получатель в локальной сети не знает, что с ним делать.
Я про вот эту возможность говорю:
>>>> Как известно, Yggdrasil позволяет дополнительную маршрутизацию IPv4 и IPv6 сетей, помимо сети 0200::/7. Т.е. позволяет “пробросить” любые подсети через сеть Yggdrasil между двумя хостами. Тут описывается, как это сделать на Linux-машинах.

Скажем, у нас есть схема ниже и нужно через Ygg-тоннель наладить связь между хостами А (интерфейс lo с адресом 172.20.18.97/28) и С (интерфес ens18 с адресом 10.0.0.5/24). Хосты B и C в одной локальной сети, а по Yggdrasil есть связь между хостами А и B.

howto.ygg/doku.php?id=yggdrasil:tunnels

В версии 0.4 это убрали, но что из этого осталось и как проявит себя — непонятно.

Ну и вот эти страшные слова:
>>>

Например, с помощью GRE туннеля внутри Yggdrasil можно настроить на удаленной машине шлюз в интернет. Т.е., вы на своей домашней машине с помощью Yggdrasil можете соединяться с удаленным сервером, который будет маршрутизировать ваши данные, упакованные GRE в интернет, и c точки зрения использования всё это будет происходить аналогично тому, как это происходит при установке OpenVPN-соединения или L2TP/IPSec.

В 0.4 от проброса подсетей не осталось ничего. Проброс через GRE вам тоже не угрожает, если вы, как администратор, его сами не настроете.

Желательно проверить какие порты светят в ygg. Когда я пробовал ту штуку оказалось ssh по умолчанию цепляется на все доступные интерфейсы. А учитывая что машина локальная и сложность того пароля... В общем nmap в руки и закрывать все ненужное.

Я могу сейчас открыть через любой браузер сайт хостящийся через Yggdrasil

Спасибо за статью! Изменения нахожу оптимистичными :)

I2P через Yggdrasil 0.4 работает определенно быстрее.

Поддержку openwrt очень хочется, но похоже придётся всё руками ставить.

Конкретно этим вопросом я не задавался, но неоднократно видел обсуждение в чате русскоязычного сообщества: Yggdrasil_ru в телеграме, а также в IRC http://[324:71e:281a:9ed3::41]/, канал #howtoygg. Думаю, вам не откажут в совете.

Sign up to leave a comment.

Articles