Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 229
Сеть Yggdrasil заблокирована в России. По крайней мере у Дом.Ру.
Что именно заблокировано? Веб-сайт? Или какой-то конкретный публичный пир?
Протокол. Две недели назад пытался подключиться. Без КВН не смог.
Что-то у вас специфичное. Либо пир выбрали заблокированный по какой-то другой причине, либо ваш провайдер дурит. У всех людей в русскоговорящем сообществе всё работает.
Несколько серверов на разных провайдерах. Подключаюсь ко всем напрямую без проблем, точки входа и выхода домру, рт, гмтс, мтс, билайн - все работает.
Ок. Попробую еще раз, попозже.
Круто, спасибо, подключился! Но:
Что всё-таки делать с отсутствием https? Пока не видел ни одного сайта с ним.
Была информация, что нужно использовать отдельный файерволл, т.к. виндовый воспринимает входящий траффик как локальный и всё пропускает. Any comments?
HTTPS в принципе внутри сети не нужен, так как трафик и так шифруется. НО! Ничего вам не мешает использовать обычные домены с IPv6-адресами Иггдрасиль, и выпускать нормальные TLS-сертификаты на такие сайты у того же Let's Encrypt. Вот пример: https://start.yggdrasil.link
В винде часто VPN-интерфейсы считаются приватными сетями, желательно переключить интерфейс в режим публичного, команду можно нагуглить.
2. Бывают случаи, когда пользователь заходит в проводнике в “Сеть”, появляется уведомление "общий доступ к файлам отключен" - если включить, то Yggdrasil сеть становится или приватной (другие правила брандмауэр), или для всех публичных сетей открывается доступ к файлам. Тут за Win нужно приглядывать.
Но дополнительный firewall не вижу смысла ставить, все решается через брандмауэр.
Обычно Yggdrasil является публичной сетью в Windows.
В своих кейсах использовал такой .cmd быстрой настройки
# Сделать сеть Yggdrasil публичной
powershell -Command "Set-NetConnectionProfile -InterfaceAlias 'Yggdrasil' -NetworkCategory Public"
# Отключить все правила на входящие подключения в брандмауэер для публичных сетей
powershell -Command "Get-NetFirewallRule -Direction Inbound | Where-Object { `$_.Profile -match 'Public' } | Disable-NetFirewallRule"
# Открыть необходимые порты для всех сетей
# Ping IPv6 всем
netsh advfirewall firewall add rule name="Ping IPv6" dir=in protocol=icmpv6 action=allow profile=any
# Открыть доступ к файлам и RDP конкретному пользователю Yggdrasil
netsh advfirewall firewall add rule name="Yggdrasil Client - user" protocol=TCP localport=139,445,3389 dir=in action=allow remoteip=201:cafe::cafe:cafe:cafe:cafe
Там же публичный (в пределах игдрасиля) адрес появляется? Надо фаирвол настраивать правильно. В типичном шиндоус компьютере итишника может быть открыто всё что можно и нельзя. Особенно сейчас когда приходится скакать по прокси и туннелям туда сюда не глядя по сторонам.
Не понятно что значит достаточно любого пира для связи со всеми и кто такие эти пиры.
Любой клиент в сети становится маршрутизатором для всех остальных что ли.
Если у меня в локальной сети несколько компов которым запрещено выходить в интернет и 1 кому разрешено то они все через него уйдут?
>>Любой клиент в сети становится маршрутизатором для всех остальных что ли
Вот да. Написано как будно для маршрутизации нужно скачать карту всей сети на устройство, либо опросить мультикастом всю сеть
на десятках-сотнях тысяч устройств перфоменс может встать и выйти
Насколько понимаю в yggdrasil можно управлять тем что можно и нельзя с помощью firewall. Т.е. на узлах промежуточных нужно разрешение для forward трафика.
Достаточно любого пира
Это значит, что достаточно любого публичного интернет-пира для связи. Затем карта сети передается вашему пиру. Пир - промежуточный узел.
Да, еще - в ygg есть возможность выдать локальным устройствам адреса из сети 300::/64, так вы можете например, с роутера соединить устройства с сетью ygg, которые не поддерживают установку клиента ygg.
Есть Tailscale - коммерческая оверлей сеть со множеством инструментов внутри. Есть описанная вами - несомненно интересная и имеющая преимущества перед Tailscale.
Вопрос - не задумывалось ли сообщество о коммерциализации, чтобы за счет этого вытаскивать из длительной беты в интенсивное развитие? Просто вижу динамику развития Tailscale и она радует.
При том что сам Tailscale остается в значительной части бесплатным (Headscale, базовые фичи).
Комерциализация открывает точку давления. Кажется сейчас этого стоит максимально избегать.
Да, но можно же разделять. Базовые возможности независимы, расширенные, с которых инвестируется базовые - коммерческие.
Примеров достаточно.
Корпоратам нужен VPN именно как сеть. Существующие протоколы скажем так, несовременны.
Если описанное решение может быть посажено для корпоратов, привиты дополнительные инструменты специфичные для корпоратов же, и с дохода автору статьи будет капать стимул - кажется хороший вариант.
Интересно, возможна ли здесь комерциализация на базе блокчейна по аналогии с тем, что пытается сделать gonka ai?
tailscale это американская контора, как понимаю. В любой момент они могут сказать "извините санкции", и все накроется.
Фактически, они уже закрывали какое-то время назад свой сайт и deb-репозиторий для клиентов из РФ, но потом открыли обратно.
При этом сам контроллер и релеи в ЕС никогда не переставали работать: авторизация, подключение, всё остальное.
В любом случае это в основном способ p2p связи и есть Headscale, который можно поднять и внутри РФ.
Tailscale как пример коммерциализированной сети которая и без коммерции работает. Ниже написано про Headscale. В официальных клиентах можно настроить работу с headscale что здорово.
Спасибо за статью, интересный подход.
Какие-то другие алгоритмы кроме spanning tree рассматривали для вашей задачи? Идеи из DUAL, например?
И что происходит с сетью после выхода из строя root и перестроения? Как на трафик и топологию будет влиять нестабильный root и его частая смена (флапинг)?
Одно время казалось что проект помер как и Hyperborea. Те вроде так и не смогли побороть проблемы плохой связи при масштабировании и клиенты не дописали нормально...
Прикольно если у этого дерева будет какое-то развитие.
Если провайдер не поддерживает ip v6, будет работать через такого провайдера?
пользуюсь Yggdrsasil с момента версии 0.3 (сейчас 0.5 - дваждны ломалась совместимость).
1. удобно подключаться к своим linux cli по ssh - у меня IP не меняется для обоих сторон, хотя я могу фактически переключаться между разными интернет каналами, при отключении сети таймаута нет, сессии не отваливаются.
2. конечно же очень удобно ходить между своими хостами напрямую, не строя хитрые vpn схемы.
3. да, трафик идет через мои узлы - это нормально. на моих vps есть ygg, в том числе в listen режиме - по сути public node, но для меня.
4. когда падает интернет на одной части сети, но при этом есть L3 линк до соседнего узла на котором есть выход в интернет, то до yggdrasil узлов доступ будет.
5. на vps поднимаю белый сайт с nginx proxy_pass через yggdrasil до какого то моего физического устройства где исполняется что-то. например до IP камеры внутри сети, за несколькими NAT.
6. есть последователь идей Yggdrasil - Mycelium. не уверен что он лучше, там QUIC протокол используется вроде только, и маршртузиция по другому устроена. @Revertis может ещё расскажет об этом.
7. Да, в РФ в последние недели начинаются проблемы и с Yggdrasil тоже - коннект может залипнуть на минуты. это не постоянно, но уже бывает заметно.
8. Yggdrasil поддерживает возможность соединяться с хостами (примеры из документации) :
tcp://1.1.1.1:1234(TCP)tls://1.1.1.1:1234(TCP+TLS)quic://1.1.1.1:1234(QUIC+TLS)socks://2.2.2.2:2345/1.1.1.1:1234(TCP via SOCKS, i.e.tcp://1.1.1.1:1234via the proxy at2.2.2.2:2345)sockstls://2.2.2.2:2345/1.1.1.1:1234(TCP+TLS via SOCKS, i.e.tls://1.1.1.1:1234via the proxy at2.2.2.2:2345)unix:///path/to/sock.sock(UNIX)ws://1.1.1.1:1234orws://1.1.1.1:1234/path(WebSockets, Yggdrasil 0.5.7 or later only)wss://1.1.1.1:1234orwss://1.1.1.1:1234/path(WebSockets+TLS, Yggdrasil 0.5.7 or later only)
в итоге если заворачивать в socks5, то можно подключиться к своему комьютеру за LTE модемом в "безопастном" не-интернете, лагать конечно такой шелл будет, но лучше чем ничего.
Здравствуйте! Есть несколько известных реализаций децентрализованных сетей. Помимо Yggdrasil, есть например Zerotier, Tailscale, Netbird... Ищу наиболее полное их сравнение... Сложно, не находится. Сам пользуюсь Zerotier, но в активном поиске альтернатив. Поделитесь, пожалуйста, ссылками для сравнения. Заранее спасибо!
Это сравнение важно разделить на две группы: ZeroTier, Tailscale и NetBird — это корпоративные SDN-сети (программные сети), а Yggdrasil — это чистый Mesh-протокол.
Вот подробный разбор по ключевым критериям:
1. Архитектура и централизация
ZeroTier / Tailscale / NetBird: Это «звездообразные» сети (Hub-and-Spoke). У них есть центральный сервер управления (координатор). Он помогает устройствам найти друг друга и обменяться ключами. Если центральный сервер (или его домен) заблокируют в РФ, ваша сеть может перестать работать, пока вы не настроите собственный контроллер (например, Headscale для Tailscale).
Yggdrasil: Полностью децентрализован. В нем нет главного сервера. Устройства соединяются напрямую (P2P). Даже если «выключить» половину интернета, оставшиеся узлы продолжат общаться между собой.
2. Принцип работы IP-адресов
ZeroTier / Tailscale / NetBird: Создают виртуальную локальную сеть (обычно в диапазоне
10.x.x.xили100.x.x.x). Вы сами или контроллер назначаете адреса устройствам. Это удобно для удаленного доступа к домашнему ПК.Yggdrasil: Каждое устройство получает уникальный IPv6-адрес, который генерируется из вашего криптографического ключа. Этот адрес неизменен, где бы вы ни находились, и он глобально маршрутизируем внутри всей сети Yggdrasil.
3. Устойчивость к блокировкам (в РФ)
Tailscale: Базируется на протоколе WireGuard. WireGuard легко распознается системами DPI и активно блокируется многими провайдерами в РФ. Чтобы он работал, нужны дополнительные «костыли» (маскировка).
ZeroTier: Использует собственный протокол поверх UDP. Блокируется реже, чем чистый WireGuard, но центральные серверы (планеты) могут быть внесены в черные списки.
NetBird: Также использует WireGuard, поэтому риски блокировки протокола такие же, как у Tailscale.
Yggdrasil: Самый живучий. Может работать через TCP, TLS (маскируясь под HTTPS) и даже внутри других туннелей. Его сложнее всего «вырезать» целиком из-за отсутствия центральной точки отказа.
4. Простота использования
Tailscale / NetBird: Самые удобные. Вход через Google/Microsoft/GitHub, и всё работает «из коробки». Идеально для доступа к файлам или SSH.
ZeroTier: Чуть сложнее, нужно вводить ID сети, но всё еще очень дружелюбно к пользователю.
Yggdrasil: Для гиков. Нужно вручную искать пиров, править конфиг-файлы (на Android чуть проще, но всё же). Это инструмент не для «удобства», а для автономии.
Что выбрать?
Если нужно просто зайти на домашний комп из кафе — ставьте Tailscale (пока работает).
Если вам нужна независимая сеть, которая будет работать даже при жестких блокировках и "чебурнете" — выбирайте Yggdrasil.
Сложно, не находится
А их в целом и нет. Их никто полноценно целую вечность не сравнивал, и это не все известные мне проекты, есть ещё всякие netmaker, nebula, остальные сходу не вспоминаются. Выделю немного информации которая сразу всплыла в голове по перечисленным, на полное сравнение не претендую, это достаточно геморройно и тянет на полноценную статью:
ZeroTier - L2, Tailscale/Netbird - L3
Селфхост всех трех доступен, но с ограничениями. Официальный controlplane для Tailscale отсутствует, есть неофициальные headscale/ionscale, есть форк cylonix со своими клиентами. Помним что альтернативные controlplane реализуют функционал закрытого сервера не полностью, но для дома обычно нормально, ionscale нативно позволяет создавать множество tailnet на одном сервере. Для headscale есть несколько веб-серверов. Для контроллера ZeroTier тоже были веб-ообертки. Netbird целиком opensource, вместе с контроллером и веб-панелью.
Tailscale - userspace wireguard, Netbird - kernel wireguard. ZeroTier тоже в userspace.
Как продукты Tailscale/Netbird похожи. Из таких фич которыми они прям могут выделиться на мой взгляд это то, что в Tailscale кроме их родных геораспределенных релеев доступных всем (даже для неофициальных серверов можно прицепить), пусть они и не самые быстрые, добавили возможность использовать свою ноду в сети как релей когда не удается создать прямое подключение, хотя и релеи тоже можно селфхостить и даже ограничить доступ только внутри своей сети. Ну и на SaaS без проблем работает 4via6 и 6via4 чего не скажешь на альтернативных. А у Netbird недавно зарелизили возможность использовать его как реверс-прокси к сервисам внутри твоей сети, такой, аналог tailscale funnel но без привязки к вендору. Ну и релеи в Netbird при необходимости тоже можно заселфхостить
P.S. самые приятные мобильные клиенты у tailscale
Здравствуйте, я мало что в этом понимаю, но не могли бы вы обьяснить для чего Иггдрасиль нужен, он же не как впн, не обходит блокировки и тд. Для чего он?
Похоже что андроид не может 2 впна одновременно держать. При этом андроид клиент для yggdrasil сам не умеет перенаправить трафик на прокси в этой сети, как впн для интернета не пригодно вообще?
Для ламеров непригодно.
Это баг или фича?
Пахнуло элитарностью.
Сеть пока небольшая
Это не удивительно, если с неофитами общаться с таким снобизмом.
Да, согласен, — но я даю поблажку такому общению понимая, что статью пишет и ведет энтузиаст, видимо инженер проекта, если не один из создателей, и глаза у него — чую красные от работы!
— «Понимаешь?… товарищ.».
Плюс тема очень горячая.
ну посмотрите Вы на Линуса, который Торвальдс по отцу, — ну и чего, больно он любезный? Такой же крипто-фрик… без пресса ситуации
Простим? Хабр торт? Снисходим?
Христос Воскрес! /так или иначе❤️
На некоторых устройствах и в некоторых конфигурациях порог входа высок. Плюс, для выхода в инет нужен VPS в нормальной стране, и настроенный прокси, например. Думаете, ламеры с этим справятся?
Да, например в моем случае на телефон без бубна не установить (айфон). Ну и VPS в Италии не нужен, да и протокол не для этого же создавался)))
Ламеры нет, а вот хомякам полезно будет почитать хотя бы))
👋
Вопрос - для развития сети нужен ли низкий порог? Станет ли она лучше (производительнее, доступнее) в результате наплыва?
Или наоборот - высокий порог это залог стабильной работы, пускай и с несколько элитарным сообществом?
Есть Yggstack-android (https://github.com/DrewCyber/yggstack-android/)
Может работать как SOCKS-прокси(для доступа в Yggdrasil) и пробрасыватель портов на узлы Yggdrasil (последнее я не пробовал). Tun-устройство не делает, слот VPN не занимает.
Хочу запустить на Yggdrasil децентрализованный краудсорсинговый проект объективного анализа достоверности информации и репутации ее источников. Кто может помочь?
А что-то вроде точек выхода в "обычный" интернет можно сделать? Если таких много создать, то это способствовало бы распространению
Это же ipv6 сеть. Всё что можно в обычной сети сделать, то же самое можно в yggdrasil повторить.
Насколько знаю ещё делают мосты между yggdrasil и tor и yggdrasil и i2p.
можно ли через узлы Yggdrasil проксировать свой выход в интернет, например, установив Yggdrasil на своём Нидерландском VPS-сервере? -
Да, это один из самых эффективных способов использования Yggdrasil для обхода блокировок. В такой схеме Yggdrasil выступает как транспортный уровень (защищенный туннель), внутри которого вы запускаете обычный прокси.
Поскольку Yggdrasil умеет маскироваться под TLS (порт 443), для цензуры это соединение выглядит как обычный веб-серфинг до вашего сервера, а внутри него идет ваш чистый интернет-трафик.
Как это реализовать (пошагово):
1. Настройка на стороне VPS (Нидерланды)
На сервере вам нужно запустить две вещи: сам Yggdrasil и прокси-сервер (например, Dante для SOCKS5 или Gost).
Установите Yggdrasil и настройте его на прослушивание входящих соединений по TLS (чтобы смартфон мог подключиться).
Установите прокси-сервер, который будет «слушать» только внутренний IPv6-адрес Yggdrasil вашего сервера.
Пример на Gost:
gost -L socks5://[ваш_yggdrasil_ipv6]:1080
Важно: Убедитесь, что в конфиге Yggdrasil на сервере разрешены входящие соединения (
Listen: [tls://0.0.0.0:443]).
2. Настройка на смартфоне (Android)
В приложении Yggdrasil в разделе Peers добавьте ваш сервер:
tls://IP_вашего_сервера:443.Нажмите Start. Теперь ваш смартфон видит сервер по его внутреннему адресу (начинается на
200:...).
3. Выход в интернет (два пути):
Вариант А: Через настройки прокси в приложениях (Рекомендуемый)
В Telegram или браузере (например, Firefox с расширением FoxyProxy) укажите:
Тип: SOCKS5
Хост: [Внутренний_IPv6_сервера_в_Yggdrasil]
Порт: 1080
Плюс: Трафик идет точечно, меньше нагрузка на батарею.
Вариант Б: Весь трафик через Yggdrasil (VPN-режим)
Для этого на сервере нужно настроить NAT и IPv6-форвардинг, чтобы он пересылал пакеты из сети Yggdrasil в большой интернет. Это сложнее в настройке (нужно править
iptables), но позволяет завернуть вообще весь трафик телефона в туннель.
Почему это лучше обычного VPN?
Устойчивость: При прочих блокировках ваш Yggdrasil-туннель (TLS) продолжит работать.
Скрытность: Вы подключаетесь к своему личному IP, которого нет в списках публичных VPN-сервисов.
Гибкость: Вы можете соединяться с сервером даже через цепочку других узлов, если прямой доступ к IP сервера вдруг ограничат.
Нейронка дала совет:
«Если вы хотите, чтобы ваш Telegram или WhatsApp работал через Yggdrasil (например, чтобы скрыть IP от провайдера или обойти блокировку), это делается так:
На Android: В приложении Yggdrasil включите тумблер «Enable VPN». После этого весь трафик телефона пойдет через Yggdrasil. Теперь Telegram будет думать, что вы выходите в сеть через VPN-узел вашего пира.
Через SOCKS5: Если на каком-то узле Yggdrasil поднят прокси-сервер (многие публичные узлы их предоставляют), вы можете прописать его адрес прямо в настройках Telegram (Настройки -> Данные и память -> Прокси).»
Рабочий ли...?
Второй пункт верен.
В приложении для андроида нет такого тублера. Чувак не надо сюда гопоту копипастить, это крипово.
Пытался завести телеграмм через socks5, через публичные узлы, и не заводится, пробовал через публичный [324:71e:281a:9ed3::fa11]1080, сама сеть Иггдрасиль работает в вот телеграм даже не пингуется
Есть у меня важный вопрос, потому что я сам подумываю над relay-системой. Самый главный вопрос всего этого дела - каждый пир должен знать адрес другого пира, то есть по сути скрыть адреса нельзя by design, иначе сеть упадет, т.к. сервер не узнает о следующем relay. К чем я это - как обходится проблема того, что просто получив адреса пиров, по очереди их резать? То есть условный бот подключается к сети, видит адрес пира, сразу отправляет его в блок на ТСПУ, передподключается - адрес уже другой, а прошлый в блоке, снова узнает адрес, снова в блок и while len(nodes) > 1? А оно ведь еще и параллелится.
Если вы подключаетесь к какому-то пиру, то только его айпи вы и можете видеть. То есть связать клирнет IPv4, например, с YGGv6. О том, какие IP в клирнете имеют другие пиры вы не узнаете.
Но я же могу его сразу в бан отправить? Запустить 1млн параллельных пиров не проблема даже для компании, а для них-то - плевое дело.
Зачем его в бан отправлять? Вы о чём?
Ну если я РКП. Я подключился к пиру, получил клирнет ipv4, сразу передал на ТСПУ - он заблокировал доступ к этому ipv4. И так я сделал параллельно с кучи VM, скажем, параллельно с 1млн VM (там как я понимаю мощность не нужна). Получил 1млн клирнет ipv4, забанил, повторил.
Я это все к тому, что если нет возможности прятать клир ipv4 от РКП, то сеть не устойчива к блокировкам. Я уже не первый месяц думаю, что сделать mesh-сеть с нодами, которые одновременно и relay и outbound до телеги (если есть доступ), а inbound через простую проксю до любой ноды - хорошая идея, но я не могу придумать алгоритм, который надежно маскировал бы ноды, иначе их можно все найти и забанить.
Я подключился к пиру, получил клирнет ipv4
Вы полностью не понимаете как это работает.
А объясните мне, пожалуйста, если не сложно, может я правда не понимаю, но как можно установить p2p, не зная клирнет IPv4?
Вы подключаетесь к сети УЖЕ ЗНАЯ клирнет-айпи некоторого пира. Айпи других пиров вы никак не узнаете, подключившись к сети.
Эта штука решает проблему централизованного впна. Глобальность для нее это побочный продукт, вобщем то ненужный.
Представь что у тебя есть несколько точек с белым адресом в интернете, допустим это роутер дома, роутеры в нескольких офисах и виртуальные серверы еще где то и ты хочешь их всех связать через впн (в локальную сеть так что бы ты мог с ноутбука из любого места доступаться в любое место в этой сети).
Если использовать обычный впн с выделенным сервером то когда он упадет/залагает/будет заблокирован, вся сеть перестанет работать, хочется его как то продублировать. А если он еще и будет связывать клиентов напрямую через дыры в нате и прямые соединения то вообще шикарно.
Если в конфигах yggdrasil будешь прописывать только свои собственные серверы то получишь то что надо, впн с несколькими взаимозаменяемыми серверами и с минимальными усилиями по настройке и поддержанию работоспособности.
Под блокировку тут могут попасть разве что виртуалки за границей.
Никакие IP адресса сети интернет не становятся открытыми. Пиры видят только ближайшие пиры, а те внутренние IPv6 адресса видят только «собеседники».
я так понял.
Другими словами: тов майор может войти в сеть, и максимум увидеть соседние пиры (и из внутренние в этой сети IPv6 адресса. Если он отправит адреса своих соседей в РКН, но либо не нейдут эти адреса в сети нормального интернета, либо они будут принадлежать каким-то реальным владельцам в нормальном интернете не в меш-сети Играсил. Как я понимаю.
Вопрос тут не столько в том, что он может увидеть глобально, сколько о том, что для p2p ему нужен реальный адрес в сети, а не адрес в mesh, если я правильно понимаю. То есть на каком-то этапе пакет, адресованный от клиента А клиенту Б должен смапить адрес mesh IPv6 на clearnet IPv4 (или IPv6), и я не понимаю, как можно это сделать, не раскрыв при этом адрес клиента Б? Какой-то внешний роутер а-ля DNS, но это ведь тогда та самая точка отказа, нет?
для p2p ему нужен реальный адрес в сети, а не адрес в mesh, если я правильно понимаю.
Неправильно понимаете.
пакет, адресованный от клиента А клиенту Б должен смапить адрес mesh IPv6 на clearnet IPv4 (или IPv6)
Нет, пакеты летают уже по созданной паутине, новых линков не образуется.
А, понял.
для внешнего наблюдателя наверняка найдется пачка инструментов, чтобы идентифицировать сам факт использования этой сети поверх сети интернет — это да. Точно так же как нынче палят ВПНы.
Спросите любой удобный для вас ИИ, ибо я не вникал еще в протокол.
Бегло прикинуть: можно на уровне приложения прятаться под почтовое приложение, другие варианты. Но думаю такого тама нету. возможно такое можно сделать сторонним разработчикам быстро и сердито, но я не знаю ничего об открытости протокола и прочее.
спросите ИИ детали, а потом к автору топика стучитесь.
Это о методах борьбы с впн в рф. Роскомнадзор местами даже на банальный ssh нападает, пытается его замедлять потому что через него можно сокс прокси пробросить.
Yggdrasil очень удобен для объединения небольших локальных сетей. Ему не нужен центральный сервер, трафик ходит напрямую. Все легко настраивается и маршруты выбираются автоматически.
Того же можно добиться с помощью openvpn, но не всем по силам его настроить и весь трафик будет идти через центральный узел (кстати, если сервер внутри страны и vpn используется для объединения локалок, то есть шанс что ркн его не тронии, по крайней мере пока, а если тронет, после гневного письма провайдеру, есть шанс что вернёт)
Первое время в ygg сталкивался с большим пингом. Потом поменял tls-соединения на tcp и quic и стало быстрее, чем через openvpn: если узлы слинкованы, трафик идёт напрямую, а не через центральный сервер.
Есть пакет для OpenWRT. Но рекомендую заводить его как отдельную зону на firewall и открывать доступ внутрь по белому списку.
Вообще, ygg задумывался как большая локалка для друзей, а не как даренит, в отличие от тех же i2p и tor.
А можно пример подобного объединения?
Иногда очень актуально.
Берём 2 локалки.
В качестве роутера используем openwrt на железке, с достаточным количеством flash (например, прошитый ax3000t)
На роутер ставим ygg с плагинами для luci
Создаем интерфейс для ygg. Прописываем входящие и исходящие пиры. Желательно, чтобы хотя бы на одной стороне был белый IP, можно динамический ipv6.
Настраиваем интерфейсы, чтобы внутри раздавались адреса ygg (начинаются с 300:)
Создаем зону для ygg в firewall. Прописываем стандартные правила "всех выпускать, никого не впускать".
Записываем префиксы, которые сгенерировались для наших подсетей. Создаем в firewall на каждом роутере белый список и разрешаем транзит для них.
В общем-то и все. Любое устройство с поддержкой ipv6 получит адрес и по этому адресу будет доступно из остальных сетей.
Особенность ipv6 сетей такова, что каждый интерфейс может иметь много адресов. Поэтому, если не накосячил с маршрутами, публичный ipv6 вполне будет работать параллельно с ygg.
Теоретически, если бы провайдеры нормально работали с ipv6 (не только давали доступ, но и выдавали постоянный префикс, который не менялся динамически - отдельные лучи поноса МГТС и всем мобильным операторам), а ещё лучше, если бы каждый мог бесплатно получить провайдеро-независимый префикс ipv6 и подключить его к нескольким провайдерам, то в ygg не было бы особой нужды. Но имеем, что имеем.
Отдельный профит ygg - любые p2p приложения (syncthing, jami, qtox и т.д.) гораздо лучше работают с прямыми адресами, чем через nat. Ygg - способ дать им такие адреса, когда остальные варианты не доступны. Можно добавить их порты в исключения на firewall.
Отдельный профит ygg - любые p2p приложения (syncthing, jami, qtox и т.д.) гораздо лучше работают
А кто-то пользовался syncthing?
Как впечатления?
Я пользуюсь для синхронизации блокнотов в Joplin. Впечатления положительные.
Как и с мессенджером jami, чем больше устройств, тем лучше работает. Держу дополнительный профиль на старом телефоне, который всегда дома на зарядке.
Через публичные релеи синхронизируется медленно, желательно иметь ipv6 дома или связь через ygg, как написал выше. Либо объединить сети через vpn, что, практически, одно и то же. Либо поднять свой релей на белом IP (вроде, можно сделать это только для себя).
Пользуюсь с 0.14.лохматой версии, в постоянной синхронизации папки с некоторыми конфигами и консольными тулзами между ПК и ноутом (оба на винде), а также real time бекап важных папок на несколько VPS-ок, а и ещё выкачивание фоточек с телефонов на NAS (но от этого вскоре планирую отказаться в пользу Immich). Суммарно около 100к файлов на чуть больше 500 Гб сейчас.
Все это внутри VPN на базе AmneziaWG с указанными вручную адресами для пиров Syncthing, публичный discovery выключен.
зачем отдельную заону? можно просто как wan назначить и все
Что будет, если ркн забанит публичные пиры в рф?
Подключитесь к непубличным, их дофига.
Их надо будет как то найти. И прописать в конфиг. Это самая странная особенность программы, найденные в процессе работы пиры не сохраняются про запас, механизма обновления публичных пиров нет, изначально ни одного пира нет, надежда только на локальное обнаружение.
Поднимите свои. Подружитесь с людьми.
Поднять свои сервера что бы пользоваться zero config оверлей сетью для которой не нужны сервера?
Кстати а насколько большой и сложный там код, если попросить клода добавить возможность автоматически сохранять\загружать всех виденных пиров которые отзывались за последние хх дней он справится или что то принципиально этому препятствует и лучше даже не начинать?
zero config
Кто вам такое сказал?
сохранять\загружать всех виденных пиров
Что значит виденных? Поиска, как такового, не существует.
Скорей вопрос такой - пока публичный пир был онлайн и отдавал адреса для маршрутов были и другие пиры онлайн через которые маршрут строился. Возможно ли в случае отказа соединения с публичным прописанным пиром начать проверять адреса из прошлого кэша в надежде выйти на сеть и получить новые маршруты? Опять же если сеть уже поднята и функционирует в каком-то масштабе, но публичный пир недоступен (отрезало белыми списками) есть ли возможность возобновления коннекта после перезагрузки, даже чтобы жить в локальном сегменте?
был онлайн и отдавал адреса
Такого не происходит. Нет обмена пирами.
То есть маршруты идут через публичный пир и в обход него по ближайшим непубличным пирам коннекта не строятся? Иначе мой инстанс игга должен был бы знать соответствие ip4 адресов с ближайшими точками маршрута от условного моего роутера до белого роутера васи в соседнем доме с поднятой слушающей нодой.
Я малость запутался. Публичные пиры принудительно корень локальной ветки или возможна самоорганизация сети между мной и публичным пиром в том числе построение прямых, или с меньшим числом прыжков, маршрутов без непосредственного участия публичного пира в передаче данных?
В мицелии так же или более "автономно", кстати? А то гугловская нейронка настаивает на существовании ключа --peer-store для указания на бд кэша пиров, о которых ни код на гитхабе ни мануалы не слыхивали.
Маршруты рассчитываются по уже проложенным связям. Всё.
Любой узел с двумя и больше линками может стать промежуточным узлом для трафика.
Корнем считается тот, у кого адрес "выше", просто как основа, от чего считать дерево.
Всё, не придумывайте новых сущностей.
Вообще, есть jamper, который пытается подключиться напрямую к целевому хосту, если возможно. Он ставится как отдельный сервис.
Сеть ygg предполагает, что вы прежде всего обединяетесь с теми, кто вам интересен. Дальше, если они имеют связь дальше, то через них пойдут маршруты.
Да, есть список публичных пиров для каждой страны (поднятых энтузиастами), но технология делалась для объединения локалок, а не для этого.
Прочитал и статью и комментарии. К сожалению, остались те же вопросы, что и уже получившие здесь ответы типа "вы полностью не понимаете, как это работает".
Попробую все-таки озвучить самй мучающий меня.
Это сеть скорее "для себя и друзей"? Видел здесь примеры с VPSками домой через Yggdrasil, командными играми за NAT. Т.е. "все условно знакомы".
Или скорее "общественная"? (иначе вряд ли бы шла речь о количестве пользователей, публичных пирах...)
Просто сценарий использования первого кейса мне понятен. И, вероятно, даже полезен. Но я напрочь не понимаю, как обеспечивать безопасность. На одном своем VPS подцепился к публичному пиру, и все остальные мои клиенты (смартфон, ноут) стали доступны кому ни попадя, и каждый надо защищать индивидуально??? Ладно бы у меня была своя "подсеть". А то ведь каждый узел получает IP криптографически, то есть случайно, Невозможно пропистаь правило на условном iptables, чтобы отличать своих от чужих без тупого перечисления всех своих IP (пока не переустановил и ключи/IP не поменялись).
А касательно "можно публиковать свои сервисы"... Насколько часто вы пользуетесь чужими сервисами, которые вам капец как нужны, но доступны они исключительно через Yggdrasil? Для себя я слабо такой кейс представляю.
Выбор типа сети на yggdrasil - для своих или общественная - это ваше право. Какую настройку будете делать, так и будет работать. Можете на всех контролируемых узлах разрешить подключения только для своих узлов. Тогда в вашем сегменте не будет посторонних.
Если же к публичной подключение где-нибудь есть, то безопасность нужно обеспечивать файерволом. Да, нужно каждое устройство настраивать индивидуально. Нужно определить какие порты оставлять открытыми и для чего:
Например если ssh, то порт можно оставить открытым, но авторизацию сделать только по ключу
Если что-то есть с http rest api и там не предусмотрена авторизация, то оставлять порт открытым по принципу белого списка для ipv6 адресов из сети yggdrasil - т.е. только для своих адресов
Иные сети позволяют настройку файрвола игнорировать, но не yggdrasil.
Я для себя делаю excel табличку для инвентаризации моих узлов и решения какие настройки на каком узле желаю иметь.
Я даже Netbox завел ради всех своих лаб :)
Хоть в лабе тоже не проходной двор, но чисто психологически я не готов выставить лабу в открытый Интернет.
Защтитить VPS - святое. Настроить Nginx Proxy Manager для получения сертификатов и чтобы сперва спрашивал хотя бы банальный пароль - тоже. Фаерволом пускать только на соответствующий веб сервер...
Но связать лабу с Интернетом через VPS и выставить десятки LXC, VM и прочего добра в сети в паблик...
Если же им не давать ygddrasil адреса, а заходить на них через VPS, как сейчас, тогда не вижу преимуществ.
Спасибо, что поясняете. Становится понятнее.
Их не надо как-то по-особенному защищать. Половина хостов в интернете уже имеет белый маршрутизируемый IPv6-адрес, и живут с этим как-то. Файрвол в телефонах и Windows-ПК по умолчанию настроен достаточно хорошо, чтобы это не было проблемой.
Одна из прикольных фишек Yggdrasil - можно раздавать адреса с роутера или сервера в локальную сеть, так что у всех в локальной сети будет адрес в сети Yggdrasil, а настраивать придется только один комп или роутер.
Насколько часто вы пользуетесь чужими сервисами, которые вам капец как нужны, но доступны они исключительно через Yggdrasil?
не исключительно, но rutracker и flibusta там есть.
Так же как и с обычными IPv6 адресами. В фаерволе разрешаете доступ с конкретных адресов, остальным отлуп. Если хочется скорости и надежности - можно поднять свой собственный публичный сервер, но в конфиге разрешить подключение к нему только клиентов с конкретными публичными ключами. Можно сделать несколько таких серверов, в разных локациях.
Самый полезный юзкейс - связывать локалки. Например подключиться по RDP по айпишнику, из Гадюкино, с местного интернет провайдера, с серым IP, NATом, закрытыми портами и прочими прелестями к серверу в Москве. Да, это можно делать VPN'ами, но это сложнее, их блокируют, и т.д.
В целом Иггдрасиль это одна большая, глобальная IPv6 локалка, со всеми вытекающими плюсами и минусами.
В целом Иггдрасиль это одна большая, глобальная IPv6 локалка, со всеми вытекающими плюсами и минусами.
Это самое ценное для моего понимания.
Так же как и с обычными IPv6 адресами. В фаерволе разрешаете доступ с конкретных адресов, остальным отлуп.
Проблема в "каких конкретно". Когда у меня есть сетка, из которой я выдаю адреса, все понятно. Но здесь то "мои" адреса никак не сгруппированы, насколько я понимаю.
Для сравнения: В ZeroTier я назначаю своим узлам узлам IPv4 и IPv6 адреса из выбранной сети. В другом аккаунте ZeroTier у меня другая сетка. И, если я их свзываю через узел (или несколько) в обоих аккаунтах, вполне понятно, какие правила прописывать в фаерволах этих "маршрутизаторов".
А в Ygddrasil, насколько я понял, даже два соседних LXC получат "рандомные" адреса. Криптографически осмысленны, но со мной никак не связаны и на сгруппированы.
Статья написана достаточно нормально, чтобы понять и суть и устройство протокола.
Если у Вас остаются вопросы — задайте их предпочитаемому ИИ.
Мне осталось непонятно только одно - есть ли прямые связи и пробивание ната, похоже что нет.
Допустим у нас есть 2 хоста и один пир. У всех есть белые маршрутизируемые адреса, они физически могут соединятся напрямую без танцев с бубном. Они не находятся внутри одной локальной сети и не могут найти и добавить себя в пиры автоматически через локальное обнаружение.
В конфигах у хостов прописан только один этот пир. Если хост1 начнет что то скачивать с хоста2 то весь трафик будет идти через пира, они даже не попытаются оптимизировать соединение через прямую связь?
Если так тогда рекомендация добавить в конфиг парочку публичных пиров звучит несколько слишком беспечно, если пир отвалится или перегружен со связью сразу возникнут проблемы, вполне возможно что связь вообще прервется, а учитывая что конфиг автоматически не обновляет список пиров это гарантировано произойдет когда-нибудь.
Да, не попытаются. И это так и задумано.
Но напрашивается же такая фича. Почему хостам которые связываются друг с другом через меш п2п сеть нельзя попытаться поднять прямое соединение.
А пиры то хоть пытаются прямые связи выстраивать или весь трафик всех клиентов не только через пиры идет но еще и через длинные цепочки пиров?
Клиент из бразилии подключается к публичному пиру у которого в пирах прописан пир из европы у которого в пирах прописан пир из китая у которого в пирах прописан пир из... и в итоге это всё как то добирается до австралии? Огромное количество лишнего трафика на пустом месте из за того что пир из бразилии не хочет напрямую подключится к пиру из австралии потому что у него он не прописан в пирах?
Вроде метрика расстояний которые минимизируются изнутри фактически и являются задержками, поэтому маршрут будет кратчайший но не факт что быстрый. Если много людей ломанутся на небыстрый канал - задержка увеличится, маршруты перестроятся. То что прописано в публичных пирах - отправная точка сети, но не основной маршрут от пира к пиру.
Как ни оптимизируй маршрут а если у твоего пира в пирах нет никого кто рядом с целью трафик пойдет сначала от тебя к твоему пира, и далее по цепочке от одного пира к другому пока не дойдет до цели. Это многократно увеличивает количество трафика в сети, задействует кучу узлов которые тут вообще не нужны, и при этом не приносит никакой пользы кроме поддержания некоторого подобия анонимности... публичных пиров.
Это вполне приемлемо когда у тебя своя сеть на своих серверах но для общего пространства это какой то феерический бред.
Поэтому и рекомендуется добавлять пиры из тех, кто рядом. В той же стране, или стране рядом.
Да-да, всё очень плохо. И как это мы пользуемся сетью 7 лет???
А как именно пользуетесь? не хватает именно практических примеров, читаешь статью - вроде прикольно, но как к себе приспособить не очень ясно.
Так же как обычным впном(не для раздачи интернета), для соединения компов и локальных сетей через интернет. Если раньше не использовал то наверное тебе не нужно просто.
Многое сильно упрощается, например тут можно оставить свой "впн сервер" открытым без пароля, с точки зрения обычного впна - нереальная ситуация а тут вполне можно не думать об этом.
всё очень просто, на yggwiki.cc есть скрипт который пингует все публичные пиры и выдаёт табличку с задержкой по каждому пиру, выбираешь с самой маленькой задержкой и пользуешься
Такие скрипты сейчас чатгпт пишет точно под твои хотелки. Я себе сделал скрипт который раз в неделю проверяет конфиг, если там осталось меньше 10 живых пиров отвечающих на пинги то он идет на сайт с публичными пирами и выбирает из них те у кого пинг меньше и добавляет в конфиг. При этом он не трогает пиры которые я вручную добавил и ничего кроме репортов не делает если что то пошло не так.
Может быть подойдёт такое решение: сделать дополнительный регулярный мониторинг - чтобы своевременно видеть проблемы с доступом до пиров которые сам контролируешь + в зависимости от потребностей доступ до нужных услуг (т.е. некоторые контрольные ping-и по сети внутри ygg или в клирнет через ygg)
Что-то смотрю, никнейм знакомый, а потом вспоминаю, что видел твою ишью на гитхабе с жалобой на новую нестабильную рут ноду)
Я оператор ноды, которая на 230 начинается. Сейчас как раз пытаюсь намайнить что-то повыше, чем у 232.
Честно, моя главная боль с этой сетью в том, что люди выбирают как можно больше (или вообще все) пиров, из-за чего трафик между клиентами в условной Европе может начинать ходить через индийский 3G линк. Надеюсь, что в 0.6 добавят возможность адекватно отсекать таких пиров
Расскажите как эту сеть использовать в контексте игр, с примерами. И какое быстродействие в сети.
Если раздавать в локальную сеть свою подсеть от yggdrasil то между раздающим и его клиентами будет ходить ничем не защищенный ipv6 трафик, на него не распространяется шифрование, например нельзя передавать пароль от прокси и фтп открытым текстом. Как то это не очень удобно, придется на все устройства устанавливать отдельный полноценный клиент.
правильно ли я понимаю, что с наглухо оторванным в ядре ipv6 оно не стартанёт? ;)
года два назад yggdrasil работал и работал отлично, сейчас же ситуация изменилась... трафик замедляется/блокируется и сеть стала непредсказуемой на многих провайдерах, появились длинны пинги, обрывы и т.д. НО! несмотря на это замены в простоте настройки и функционала практически нет. Незаменимая штука для настройки OpenWRT роутеров, всегда можно законнектиться к самым закрытым рутерам ну или к серверам.
в свое время я даже сделал реализацию свой звонилки на базе ygg: https://habr.com/ru/articles/976430/
Но комментарий я пишу, что бы познакомить с еще более прекрасной технологией mesh сетей. Она заслуживает отдельной статьи (автору на заметку). Это Reticulum. Технология схожа с Yggdrasil в плане mesh маршрутизации, но работает поверх любых транспортов. Можно даже поверх почтовых голубей построить mesh, это будет работать... сеть уже работает по радио протоколам, через обычный интернет, через i2p и даже через yggdrasil. Технология не новомодная, а уже довольно широко известная, рабочая. Но если ygg работает как tun интерфейс на машине, reticulum создает свой тоннель без интерфейса, есть и другие отличия само собой.
Пакет reticulum пролетит часть пути по радиомосту, часть по мобильной сети, часть по i2p, часть по yggdrasil и в итоде достигнет точки назначения.
Кстати генерация адресов в yggdrasil и reticulum так же схожа и гипотетически обратно заменяема. Это значит что те же ключи на основе которых полуачется адрес yggdrasil подойдут и для адреса reticulum.
AI говорит, что Reticulum и Yggdrasil немного для разных целей.
Но спасибо, узнал и про такую
Не вдавался раньше как работает эта сеть. Пробовал проверять как впн. Сделал на впс ygg и на роутере. Добавил впс в свои ноду и все заработало, но так как провайдер замедляет по ip то скорость не поменялась. Но заработало.
И в гайдах по установке, говорится что если нужна сеть yggdarsil, то начните с публичных пиров и ссылка на github.
И вот все кто, как и я, заходят на эту ссылку и берут первые несколько нод. Думая что это просто выход в общую сеть, bootstrap, так сказать. А получается что через те несколько нод проходит весь трафик.
И тут возник вопрос, может нужен механизм для обмена нодами? Тот же самый dht. Это не вопрос к автору статьи, а риторический наверно.
Цель проекта - найти оптимальный алгоритм маршрутизации по заданным линкам.
С одной стороны нельзя рассчитывать что несколько добавленных вручную пиров будут стабильно работать всё время. В конфиге должна быть опция что бы включить автоматическую подкачку публичных пиров по необходимости, хотя бы с сайта на котором они сейчас опубликованы.
С другой если сразу добавить 2 десятка пиров то скорее всего хватит навсегда и нефиг усложнять.
Select a small number of NEARBY peers with good uptime, preferably inside your own country or neighbouring countries only.
AVOID selecting peers that are high latency, i.e. because they are geographically far away from your node.
Do not add large numbers of peers from the list!
There is no benefit whatsoever from adding the same peer multiple times using different protocols.
Сайт разработчика говорит следующее:
Выберите небольшое количество ближайших узлов с хорошей доступностью, предпочтительно в пределах вашей страны или соседних стран. ИЗБЕГАЙТЕ выбора узлов с высокой задержкой, то есть находящихся на значительном географическом расстоянии от вашего узла. Не добавляйте большое количество узлов из списка! Нет никакой пользы от добавления одного и того же узла несколько раз с использованием разных протоколов.
Какие то объяснения этим рекомендациям есть?
Один комп на дальнем востоке, второй в европе. Прямой пинг 160мс.
Вариант 1 - в пирах прописаны сами эти компы и 2 десятка самых быстрых из сайта с публичными пирами. По идее должна стабильно работать прямая связь, они же сами у себя в пирах - кратчайший маршрут будет через них самих.
Пинг ~160мс и 2% потерь, причем без нагрузки. Скорость сильно плавает. Иногда связь вообще обрывается, пропускает десяток пингов подряд.
Параллельно идет пинг через обычный wireguard и там 0 потерь, скорость более менее стабильная и высокая.
Вариант 2 - тоже самое но в пирах прописаны только 4 самых близких из публичных.
Пинг стал заметно больше, скорость меньше. Потери остались. Через публичных посредников работает явно хуже чем напрямую. Пинг и скорость очень сильно плавает.
Кто виноват и что делать как с этим жить?
Поменял протокол для пиров с tls на quic (tcp->udp). Потерь стало вдвое меньше. Скорость повыше но очень нестабильная, может 50мбит давать а может 1 и даже меньше. А с ваиргардом работающим через udp всё ровно.
Несколько пиров нужны как failover. В нормальных условиях маршруты строятся через быстрые линки, остальные в резерве. Но стоит добавить в условия помехи (привет ркн) - и у тебя может отвалиться твой любимый быстрый пир, и тогда запасные вытянут трафик. Еще полезно иметь несколько пиров в tor/i2p, на случай если публичный список целиком отлетит в бан.
Когда есть прямая связь - ygg как будто и не нужен.
А что ставят для релея на роутер Keenetic?
Скорее уже Yggdrasil-ng, но о ней я пока тут не писал ;)
Если прокомментируете хотя бы выдачу гугла по запросу keenetic+yggdrasil (там из первых трёх одна ссыль на форум кинетиков, другая на гитхаб, а третья сюда), то было бы полезно!
А то у меня вот например уже сто лет в ту-ду болтается задача "install yggdrassil 1010", а руки всё никак не дойдут, потому что непонятно, результат для меня, чайника, достижим или нет :)
А с какой целью ставят Иггдрасиль на роутер? Скорость хорошую он не обеспечит. Разве что для связи за NAT'ом по SSH.
Для доступа к самому роутеру, его настройками или сервисам. А если у него есть белый ип то для того что бы сделать из него сервер - пир. Через свой пир скорость выше и пинг меньше.
Нет, роутер в роли публичного пира будет тупить и греться. Лучше уже за роутером разместить простенькую машинку на каком-нибудь Селероне, и её уже сделать пиром.
Не публичный пир для мира, а пир для своих сетей, в основном для доступа в свою же сеть.
Если ты про то что на роутере дохлый цпу то это не должно быть большой проблемой, он же не шифрует трафик проходящий транзитом.
Хе-хе, ты удивишься :)
Даже не смотря на то, что трафик не шифруется, для его обработки в пространстве пользователя уходит очень много ресурсов :(
Во-первых — да, роутер с белым адресом (ответ @K0Jlya9), он живёт очень далеко от меня, и я в общем-то ищу все возможные способы как-то на будущее оставаться на связи с роднёй, а то керосином пахнет всё сильнее и сильнее. На нём уже и Астериск подготовлен (не знаю зачем, пусть будет), и вот помаленьку с джаббер-сервером на Prosody дрюкаюсь (но мозгов пока не хватает, да и жареный петух пока не клюнул), и i2pd болтается, а чобынет. IKEv2 сервер тоже, чтобы через VNC помочь на случай если Anydesk тоже решит свалить как Teamviewer когда-то.
Во-вторых, а что, всё прям так серьёзно в плане нагрузки? Гига — неслабый такой вроде аппарат, не помню чтобы удалось его заставить чем-то вспотеть кроме хэширования торрента.
Ставить за ним ещё что-то очень бы не хотелось — там некому даже присмотреть, никто не умеет. Даже для семейного пользования смысла нет, слишком тяжело?
помаленьку с джаббер-сервером на Prosody дрюкаюсь (но мозгов пока не хватает
Лучше попробуйте Openfire.
Даже для семейного пользования смысла нет, слишком тяжело?
Не, ну не настолько. У меня просто на Кинетике стояла Игг долгое время, но скорости ноды не хватало мне, постоянно к домашним сервакам извне линки кидал.
имхо в ygg не хватает встроенного файрвола, по дефолту включенного режима "обыватель", который игнорирует входящие пакеты. режим конечно который можно просто и быстро отключить.
Под какую ОС?
под все)
я иммел ввиду встроить в саму программу, если это возможно
Это довольно сложно и не нужно. Все ОС обладают нормальными фаирволлами.
да, да, "цели проекта другие"
наверное делать 300 фич пока база не стабильна не лучшая идея, согласен.
но чисто в утопическом будущем было бы неплохо добавить фич. которые делают использование ygg безопасным и удобным по умолчанию для простого человека.
"Конечно, пошли мы нафиг..." - фаирволлы в ОС.
ок, конкретно про андроид приложение.
в андроидовском ygg приложении было бы неплохо иметь встроенный файрволл.
потому что без рута и тд там вроде хрен что настроишь
А много у вас всяких программ слушают на всех IPv6 адресах, чтобы бояться того, что их начнут ломать хакеры? Есть сайт nmap.ygg, где можно проверить открытые порты.
В последнее время прямой пинг из дальнего востока в европу по вечерам стал подниматься до 250мс, при норме в ~130.
В yggdrasil получается повыбирать пиры вручную и найти маршрут в 140мс. Жаль что это не происходит автоматически.
Жаль что это не происходит автоматически.
Тыц. Внизу, в разделе Настройка - Автоматическое конфигурирование пиров в конфиге Yggdrasil
@Revertis. поясните пожалуйста (в статье явно не написано) про связность IPv6 -- доступны ли хосты yggdrasil из публичного IPv6 и наоборот?
Касательно торрентов - я являюсь одним из хранителей рутрекера и могу поднять ygg-узлы на своих серверах. Вопрос только в регистрации клиентов на трекерах (для этого нужна связность)
Нет, это два разных диапазона IP, поэтому мы иногда называем 200::/7 как YGGv6.
Вопрос только в регистрации клиентов на трекерах
Вот это не понял :-/
У меня в голове картинка не выстраивается, эти публичные пиры с официальной страницы, через них проходит почти весь трафик со всего мира что ли.
Допустим у меня нет своих серверов, я на всех хостах просто прописываю несколько публичных пиров из тех у кого пинг поменьше, и дальше ygg трафик между моими компами начинает ходить через публичного пира из соседнего города... Если таких же как я станет хоть сколько-нибудь заметное количество все эти пиру лягут даже без торентов.
А если еще вспомнить что маршруты внутри ygg между пирами не оптимизируются, то есть трафик ходит не прямо а через цепочку пиров то становится совсем непонятно как это выживает в реальном мире.
У меня в голове картинка не выстраивается, эти публичные пиры с официальной страницы, через них проходит почти весь трафик со всего мира что ли.
Если бы не существовало ещё сотен непубличных пиров, то так бы и происходило. Ну и если ты запускаешь где-то ноду и прописываешь пару пиров ей, то она тоже может стать хорошим маршрутом между конкретными узлами.
и дальше ygg трафик между моими компами начинает ходить через публичного пира из соседнего города...
Либо трафик между этими пирами ходит через твои компы. Все узлы ведь равноправны.
маршруты внутри ygg между пирами не оптимизируются
А я о чём написал в статье? Там есть несколько оптимизаций.
Либо трафик между этими пирами ходит через твои компы. Все узлы ведь равноправны.
Для того что бы стать равноправным узлом надо... что бы кто то еще считал тебя пиром, в реальности это только другие компы из твоей локалки, им это ничего вообще не даст, они просто пойдут по более длинной цепочке из пиров.
Это никак не отменяет того что трафик ходит по цепочке вручную прописанных пиров не пытаясь сократить маршрут. Да маршрут как бы кратчайший получается, но кратчайший он только на виртуальной карте построенной по вручную прописанным пирам...
Реальная карта отличается от виртуальной кардинально, ведь почти у каждого полноценного узла есть реальная возможность связаться напрямую с любым другим таким же узлом.
То как это работает сейчас:
[user1] - [puplic peer 1] - [puplic peer 2] - [puplic peer 3] - [puplic peer 4] - [user2]
Как это могло бы быть если бы узлы, хотя бы те кто считает себя публичными, попытались найти более короткий маршрут
[user1] - [puplic peer 1] - [puplic peer 4] - [user2]
Тут еще есть скрытая проблема с тем что узлы не пытаются контролировать качество соседей, им кажется что они идут по кратчайшему маршруту но на этом маршруте может быть плохой узел и не один.
Для того что бы стать равноправным узлом надо... что бы кто то еще считал тебя пиром
Так все узлы равны, и все линки равны. Не важно кто к кому подключается.
Да маршрут как бы кратчайший получается, но кратчайший он только на виртуальной карте построенной по вручную прописанным пирам...
И в этом и состоит цель эксперимента Yggdrasil - найти оптимальнейший алгоритм маршрутизации по заданным линкам.
Реальная карта отличается от виртуальной кардинально, ведь почти у каждого полноценного узла есть реальная возможность связаться напрямую с любым другим таким же узлом.
Ты забываешь про NAT'ы, не у всех есть возможность соединяться со всеми.
Тут еще есть скрытая проблема с тем что узлы не пытаются контролировать качество соседей
И тут ты не прав. Каждая нода ранжирует свои непосредственные линки по скорости ответа. Предпочитаются пути с, упрощенно, меньшими пингами и меньшими путями по дереву. Эти параметры умножаются друг на друга и получается результирующий коэффициент.
Так все узлы равны, и все линки равны. Не важно кто к кому подключается.
Эта фраза не имеет смысла без добавления что подключаться можно только к тем кто у тебя прописан в пирах или найден в локалке. То что твой комп может связаться с моим с моим через цепочку пиров не значит что он может проложить свой маршрут куда то кроме моей локалки через мой комп.
Ну то есть он как бы может, но для этого, каким от невероятным образом, этот маршрут должен оказаться короче других, а это, как мне кажется, возможно только с другими компами из моей локалки.
Ты забываешь про NAT'ы, не у всех есть возможность соединяться со всеми.
Я говорю про публичные пиры, или про частные сервера (которые по своим свойствам не отличаются от публичных пиров ничем кроме присутствия на официальной странице с публичными пирами). У них есть маршрутизируемые адреса, практически у всех. И через них же идёт почти весь трафик, потому что без них остается только локальное обнаружение.
И тут ты не прав. Каждая нода ранжирует свои непосредственные линки по скорости ответа. Предпочитаются пути с, упрощенно, меньшими пингами и меньшими путями по дереву. Эти параметры умножаются друг на друга и получается результирующий коэффициент.
Линки ранжируются по пингу только если у них количество хопов до цели одинаковое. То есть короткий маршрут в приоритете и пофиг что он идет через плохой узел.
Забавное.
Адрес в yggdrasil получается из открытого ключа. Что бы создать адрес надо сгенерировать пару ключей, и потом из открытого ключа берется кусок и вставляется в шаблон (подсеть+кусок хеша от открытого ключа). Что бы сделать красивый адрес надо перебирать бесчисленное количество вариантов.
Но есть лайфхак, вместе с адресом дается еще подсеть, она короче и половину от нее можно использовать свободно.
как то так
https://[302:a2a5:dead:ded::a2a5]/
Хорошо, что эту статью написали! Я 7 лет мимо проходил. Посидев вечерок с зоопарком подопытных виртуалок я проникся и мне очень понравилось) Возникли некоторые вопросы.
1) Так как адрес IPv6 самоназначается, то есть же вероятность того, что в сети могут появиться два одинаковых адреса? Возникнет коллизия. Что тогда будет?
2) Я создал тестовую закрытую сеть типа звезда, отключив поиск через мультикаст и автоматическое подключение к публичным узлам через встроенный резервный список пиров (PeerListFallback=false). Если я к этой сети подключу телефон, то она станет глобально доступной? Приложение не так гибко как десктопные клиенты и нет настроек для Listen, MulticastInterfaces, AllowedPublicKeys, PeerListFallback.
3) Хотелось бы совместить глобальную сеть и свою закрытую с расшаренными папками для файлообмена), чтобы они помогали друг другу в плане маршрутизации. Mesh всё-таки! Но, как я понял, безопасность можно обеспечить только файрволлом на стороне своих клиентов разрешая SMB только с определённых адресов. Это не проблема для сети из нескольких ПК, но добавление каждого последующего будет приводить к правкам у всех, что накладно. В линуксе как я понял это автоматизируется скриптом, для винды ничего такого не нашлось, да и подход совсем не нравится. Была идея сделать свою виртуальную локалку с NAT, выделив какой-то узел в роль виртуального коммутатора используя AllowedPublicKeys, но дальнейшее изучение дало понять что AllowedPublicKeys всё же не для того. Наверное такую архитуктуру сделать не получится?
есть же вероятность того, что в сети могут появиться два одинаковых адреса?
Вероятность меньше, чем встретить живого динозавра.
Возникнет коллизия. Что тогда будет?
Громкий хлопок и запах гари. Шучу, пакеты будут лететь то к одной ноде, то к другой. Почти случайным образом.
PeerListFallback=false
Первый раз такую опцию вижу, вы точно Yggdrasil ставили?
Если я к этой сети подключу телефон, то она станет глобально доступной?
Если на телефоне будет подключен публичный пир и пир вашей сети, то да.
Но, как я понял, безопасность можно обеспечить только файрволлом на стороне своих клиентов разрешая SMB только с определённых адресов.
Правильно.
Наверное такую архитуктуру сделать не получится?
Пока нет, но есть у меня в планах одна крутая фитча ;) Не переключайтесь! ;)
Первый раз такую опцию вижу, вы точно Yggdrasil ставили?
То есть её всё такие нет? AI надул всё таки ))) Правильнее было бы тогда чтобы Yggdrasil ругался на неизвестные опции.
А захардкоренные пиры всё же есть или нет? Если есть, то как они работают?
пакеты будут лететь то к одной ноде, то к другой. Почти случайным образом.
Практика показывает, что вот из-за таких несущественных вероятностей потом очень долгая отладка может быть. Если такое случиться, то это же ещё понять нужно будет)
...
Ещё для подключения к пиру можно задать пароль. Это удобно для масштабирования сети. Если максимальная длина 64 бита, то я ведь задам 64 бита) Но защита от брутфорса какая-то есть? В доках есть директива maxbackoff - с помощью неё можно реализовать таймаут повторного подключения при неудавшемся?
А что там с конфигами происходит. Версия которая в репах у дебиана 0.5.12-2+b4 делала нормальные конфиги, в списках были кавычки запятые
Версия с гитхаба 0.5.13 переделала конфиг. При этом похоже что работают любые варианты в том числе микс. Для людей такое может и удобно но что будет со старыми скриптами, они таких странных трансформаций не ожидают.
Это какая то самоделка или строгий формат?
Как поднять ноду
Тут всё просто:
Установить Yggdrasil. Есть пакеты для Windows, Linux (deb, rpm), macOS, Android.
А какие у ноды требования в случае Android?
Если взять довольно древний Xiaomi Redmi 4, у которого памяти 2 Гб и убогий процессор, будет работать как нода?
https://4pda.to/forum/index.php?showtopic=822143
Сегодня пара самых близких публичных пиров замедлилась до безобразия, пинг отличный а скорость около нуля. Пришлось убирать их вручную, со всех узлов где они были прописаны... Стало получше но всё равно даже не близко к тому что дают впны на ваиргарде или хотя бы небуле.
Не понимаю как с этим можно жить. Вручную добавлять пиров, обновлять, теперь еще и проверять качество как то надо.
Клиент для андроида не умеет примерно ничего. Но возможно получится даже через него завернуть интернет. Если использовать днс который все запросы перенаправляет на специальный прокси то как минимум браузер начнет работать.
То что делают сервисы типа https://xbox-dns.ru/
Я пока застрял на создании днса, он должен быть или локальным(не вариант) или ~DoH.
Прокси на который перенаправляются все запросы внутри yggdrasil работает нормально, хотя ему и приходится отправлять запросы пришедшие по ipv6 в ipv4, похоже что это вообще не проблема.
Как там дела обстоят с работой с белыми списками?) У меня он то подключается к пирам, то нет.
Это баг или фича, чем он с цпу занимается когда на него никто не смотрит?
зы какой то странный бот в тг группе Yggdrasil RU попросил написать цифру задом наперед после чего выдал постоянный бан. Это был баг или фича?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что такое Yggdrasil Network?