Публичным пиром сети называется устройство, к которому в оверлейном режиме может подключиться любой желающий. Проще говоря: узел сети, к которому можно подключиться через Интернет и соединиться таким образом с глобальным сегментом сети Yggdrasil. Список публичных пиров доступен в официальном репозитории проекта «Public Peers»: https://github.com/yggdrasil-network/public-peers, а так же по адресам:
- https://publicpeers.neilalexander.dev/
- http://[319:3cf0:dd1d:47b9:20c:29ff:fe2c:39bd]/ (внутрисетевое зеркало)
Список на сайте генерируется автоматически на базе информации с GitHub и имеет статус доступности узлов (online/offline).
Публичные пиры, к которым вы хотите быть подключены, прописываются в файле конфигурации yggdrasil.conf (/etc/yggdrasil.conf или %programdata%\yggdrasil\yggdrasil.conf) в секции Peers:
Peers: [ # Чехия, Revertron tcp://195.123.245.146:7743 # netherlands tcp://51.15.118.10:62486 ]
Комментарии не обязательны, но они могут пригодиться.
Начиная с версии 0.3.11 Yggdrasil поддерживает соединения по протоколу TLS. Это позволяет скрыть пиринговое соединение внутри обычного сеанса TLS, что в некоторых случаях может помочь обойти брандмауэр или фильтры DPI, блокирующие пиринговый трафик Yggdrasil.
Публичные пиры, поддерживающие TLS идентифицируются префиксом tls://
вместо tcp://
.
Обратите внимание, что из-за дополнительного уровня шифрования производительность через одноранговые узлы TLS может быть немного хуже, чем через обычные одноранговые узлы tcp://
.
Начиная с версии 0.5 RC1 Yggdrasil поддерживает соединения по протоколу QUIC.
Публичные пиры, поддерживающие QUIC идентифицируются префиксом quic://
.
На данный момент, использование QUIC в Yggdrasil не даёт каких-либо преимуществ, передача данных по этому протоколу может быть даже медленнее, чем при использовании других протоколов.
На текущий момент (18 декабря 2023 года) мониторилка QUIC на сайте https://publicpeers.neilalexander.dev/ работает неправильно, поэтому ориентироваться на неё нельзя (подтверждено самим neilalexander)
Начиная с версии 0.5.7 Yggdrasil поддерживает соединения по протоколу WebSocket.
Публичные пиры, поддерживающие WebSocket, в секциях Listen
и (или) Peers
конфигурационного файла идентифицируются префиксами ws://
или wss://
.
wss://
используется для подключения к публичному пиру, находящемуся за обратным прокси HTTPS (HTTPS reverse proxy).
В версии Yggdrasil 0.4.5 появилась возможность пиринга с использованием Unix сокетов. Это не вполне релевантно статье о публичных пирах, т.к., Unix сокеты можно использовать только на одной машине, но тем не менее, об этом стоит упомянуть и здесь.
Эту возможность можно использовать в случае запуска Yggdrasil на одной машине с использованием средств виртуализации или с разделением по network namespaces, или, например, для соединения Yggdrasil c Yggmail.
Для использования пиринга через Unix сокет можно прописать в секцию Peers конфигурационного файла такую строку: unix:///path/to/socket.sock
Пример:
В конфигурационном файле Yggdrasil, в секции Listen прописываем:
Listen: [ tcp://192.168.1.2:23485 unix:///var/run/yggdrasil.sock ]
Таким образом к нашему пиру можно будет подключиться по IP 192.168.1.2
, на порт 23485
и через Unix сокет по пути /var/run/yggdrasil.sock
Yggmail теперь можно запускать так:
yggmail -peer=unix:///var/run/yggdrasil.sock -database=/home/USER/mail/yggmail.db -smtp=192.168.1.2:1025 -imap=192.168.1.2:1143
Для обычного домашнего использования разработчики рекомендуют прописывать в конфигурационном файле 2-3 географически ближайших к вам публичных пира. Слишком большое количество пиров в конфигурационном файле, а так же, использование географически удаленных от вас пиров может нагативно сказаться на производительности узла и скорости доступа к ресурсам сети.
Для выбора пиров, во-первых можно просто воспользоваться упомянутым выше сайтом, на котором собраны все публичные пиры с offline / online статусами.
Ниже перечислены средства автоматизации процесса выбора пиров.
Утилита предназначена для проверки доступности пиров и автоматического их обновления в конфигурационном файле Yggdrasil, а так же, с помощью метода admin API - addPeer.
Для вывода отсортированного по скорости доступа списка доступных пиров используется флаг -p
.
С другими параметрами можно ознакомиться из описания (RU): https://github.com/ygguser/peers_updater/blob/master/README_ru.md
zhoreeq разработал скрипт, который в отсортированном виде выводит информацию о времени отклика пиров, его можно использовать при выборе пиров для своего конфигурационного файла (необходимо наличие установленного python3):
Клонируем репозиторий с публичными пирами:
git clone https://github.com/yggdrasil-network/public-peers.git
Клонируем репозиторий со скриптом:
git clone https://github.com/zhoreeq/peer_checker.py.git
Запускаем скрипт (параметром указывается каталог с публичными пирами):
python ./peer_checker.py/peer_checker.py ./public-peers/
Пример вывода скрипта:
Dead peers: tcp://[2a04:5b81:2010::90]:2000 africa/south-africa.md tcp://[2804:49fc::ffff:ffff:5b5:e8be]:58301 south-america/brazil.md ... Alive peers (sorted by latency): URI Latency (ms) Location tcp://95.165.99.73:5353 6.679 europe/russia.md tcp://yggno.de:18226 16.892 europe/russia.md ...
Любой желающий может стать публичным пиром. Для этого, чтобы другие пользователи могли подключиться к вашему узлу, как к публичному пиру, необходимо иметь прямой доступ в Интернет (белый IP). Также крайне желательно использовать для пиринга весьма производительное «железо» и широкий сетевой канал. Производительность сервера важна при больших нагрузках, т.к. нативные криптографические операции сети весьма требовательны и в случае недостатка мощности в работе пира будут возникать сбои. В настройках файерволла операционной системы необходимо открыть порт, который будет прослушивать Yggdrasil (любой, на ваше усмотрение).
В файле конфигурации Yggdrasil добавляем в поле Listen:
Listen: [ # Для прослушивания всех IPv4 интерфейсов на порту 7991 tcp://0.0.0.0:7991 # Для прослушивания всех IPv6 интерфейсов на порту 7992 tcp://[::]:7992 ]
По-желанию, адрес своего узла можно опубликовать на упомянутой выше странице проекта в GitHub, либо просто поделиться им с друзьями.
В Yggdrasil версии 0.4.6 появилась возможность задать приоритеты для соединения с одним и тем же узлом, если у узла несколько интерфейсов.
Приоритет указывается с помощью параметра URI пира ?priority=X
в секциях Peers
или Listen
, или c помощью параметра Priority
в секции MulticastInterfaces
.
Приоритет — это число из диапазона от 0 до 254 (по умолчанию 0), чем ниже значение, тем выше приоритет.
Начиная с версии 0.5 RC1 можно использовать «рукопожатие» с дополнительным паролем.
Пример:
Для секции Listen: tls://[::]:12345?password=123456abcdef
Для секции Peers: tls://a.b.c.d:12345?password=123456abcdef
Так же, пароль допустимо использовать в секции MulticastInterfaces
.
Максимальная допустимая длина пароля - 64 символа.
0. Не забудьте перезапустить службу Yggdrasil, чтобы изменения вступили в силу:
# Debian/Ubuntu: sudo systemctl restart yggdrasil # Windows: net.exe stop "Yggdrasil Service" && net.exe start "Yggdrasil Service"
1. Другие частники сети будут считаться подключенными локально, будто они с вами в одной локальной сети. Учитывайте это при настройке безопасности.
2. Редактируя файл конфигурации в Windows, не используйте стандартный блокнот и Office Word. Это испортит кодировку файла и служба Yggdrasil не сможет запуститься. Для редактирования конфига в Windows следует использовать текстовые редакторы вроде AkelPad
, Notepad2 и NotePad++
.
Публичные пиры (EN): https://github.com/yggdrasil-network/public-peers
Yggdrasil peer checker (EN): https://github.com/zhoreeq/peer_checker.py
Обсуждение
Раскройте, пожалуйста, вопрос безопасности по данному замечанию:
"Все подключенные пиры будут считаться подключенными локально, будто они с вами в одной локальной сети. Учитывайте это при настройке безопасности."
Как регулярный пользователь, насколько я понимаю:
1. Это касается только нод с открытым портом или портами в секции Listen;
2. Если на этой машине запущен например, сервер MySQL или иная другая служба, доступ к которой по-умолчанию ограничен по localhost, эти настройки должны быть изменены? Или это касается только локального пространства адресов / внутренней сети устройств Yggdrasil? То есть может ли стороннее подключение иметь доступ к локальным службам текущего сервера;
3. Также вопрос проксирования, но насколько понимаю, подключенные узлы Yggdrasil ограничены для выхода в сеть интернет через публичный пир?
Спасибо!
2. То, что запущено на localhost (127.1 или ::1/128) напрямую доступно не будет, но если другие сервисы будут доступны по адресу на tun-интерфейсе Yggdrasil, это [потенциально] может быть угрозой и тому, что на localhost. Поэтому стоит перевесить сервисы, которые не должны быть доступны через Yggdrasil, и/или настроить файервол.
3. Для выхода в интернет через Yggdrasil могут быть использованы узлы, которые соответствующим образом настроены, например, там может быть GRE/IPIP-туннель или прокси-сервер.
Для того, чтобы проверить, что у вас доступно на адресе Yggdrasil для всей сети Yggdrasil можно использовать nmap (nmap -6 -Pn <Yggdrasil_ipv6_addr>). Ну, или погуглите, на тему "как узнать открытые порты в <windows|ubuntu|debian>".
За информацию спасибо (без RSS ответ увидел не сразу)
Не сейчас, но было бы интересно почитать как это лучше организовать, например балансировка между подключениями или просто лимит на процесс. Насколько понимаю, конфигурация Yggdrasil этого не предусматривает.
C помощью tc из iproute2 можно на интерфейсах ограничения настраивать. Есть удобная обертка над tc - wondershaper.
Не хочешь иметь транзитный трафик? Подключайся только к одному узлу. Точка.
Установить пропорционально равный лимит между количеством узлов (при текущем количестве подключений, 10 мБит разве мало) или временно ограничивать нагрузку при выходе из квоты для конкретного подключения (через getPeers эта статистика имеется), имеет место быть. Это вопрос времени, видимо еще небыло прецедентов.
https://github.com/iv-org/documentation/blob/master/docs/instances.md#rules-to-have-your-instance-in-this-list
))
Можно запилить скриптик, который со случайным интервалом будет тестить подключения ко всем пирам последовательно и формировать список, ранжированный по оценкам, которые будут рассчитываться с учетом uptime, пропускной способности и т.п. Но кому-то этим надо заняться...
Это же распределенная сеть, значит нужно большее кол-во нод.
То что делать лимиты на сервис yggdrasil - это плохо, а если ограничивать для конкретного узла при выходе из квоты, полученной из статистики байтов в getPeers (т.е. по IP)
Здесь же не столько ограничить сколько защита от потенциальной атаки, потому что публичных узлов не так и много
То есть в теории можно лимитировать на конкретный узел, я только не совсем понимаю, но вроде как лимит затронет только этот узел или входящий трафик к нему, поэтому не понял при чем тут хопы (конечно если договорились не ставить общий лимит на сервис Yggdrasil и тд)
Т.е. грубо говоря - на интерфейсе tun ты можешь делать что твоей душе угодно, это твой трафик. Что либо делать с трафиком ygg на "внешних" интерфейсах - это очень-очень плохая идея.
http://[21e:e795:8e82:a9e2:ff48:952d:55f2:f0bb]/#201:23b4:991a:634d:8359:4521:5576:15b7
Да, действительно урезав трафик для одного узла, можно застопорить целую ветку сети.
Интересно, в каких случаях и когда участники такой полу-живой ветки перестроятся если допустим кто-то все же ограничит канал или просто будет перегружен?
Позже заметил, что его нет в списке, админ сервера говорит адрес правильный, но нужно настраивать.
Добавил маску подсети из (ifconfig lo inet6 add 2a02:7aa0:5000::4708) - tls://[2a02:7aa0:5000::4708]:4708 - не работает, как и другой нужный мне сервис тоже.
Что я забыл еще сделать? Порт 4708 открыт, публичный пир нормально работает с IPv4
Ответ моего хостера:
2a02:7aa0:4000::f2 is IPv6 for your server, which you can use.
Please configure IPv6 manually.
GW for your IPv6 is: 2a02:7aa0:5000::1
Netmask 64
PING 2a02:7aa0:4000::f2(2a02:7aa0:4000::f2) 56 data bytes
From 2a00:c68:1:1::2 icmp_seq=1 Destination unreachable: Address unreachable
From 2a00:c68:1:1::2 icmp_seq=9 Destination unreachable: Address unreachable
^C
--- 2a02:7aa0:4000::f2 ping statistics ---
14 packets transmitted, 0 received, +2 errors, 100% packet loss, time 13238ms
У вас IPv6 не сконфигурирован. Пропишите адрес на интерфейс.
В зависимости от дистрибутива: либо в network/interfaces, либо netplan.
GW - это гейтвэй (шлюз по-умолчанию должен быть).
https://ztv.su/knowledgebase/35/nastroika-ipv6-na-vps-vo-frantcii-i-kanade.html
Если бы не другой нужный мне сервис на IPv6 можно было подумать что не настроен LISTEN
Listen: [
tls://0.0.0.0:4708
# tls://[::]:4708
]
Для IPv6 ничего небыло указано, в общем добавил, ребутнул yggdrasil - порт слушает
netstat -tulpn | grep LISTEN
tcp6 0 0 :::4708 :::* LISTEN 308191/yggdrasil
Чуть оффтоп, но я закомментил директиву tls://[::]:4708 ребутнул через service yggdrasil restart но порт все равно слушает.
Может не тот сервис ребутнул или как оно работает на этом порту если настройки отключены
В списке public-peers есть адреса вида tcp://[xxxx:xxxx:x:xx::]:порт
Насколько понимаю, это сделано для удобства клиентов - т.к. они могут динамически выбрать адрес или подключаться к нескольким сразу
"1. Все подключенные пиры будут считаться подключенными локально, будто они с вами в одной локальной сети. Учитывайте это при настройке безопасности."
Даже если "это не цель yggdrasil" то считаю правильным добавить whitelist портов из коробки иначе это огромная дырка (точнее тунель) в безопасности и его срашно пускать локально
Вот и с Yggdrasil и его IPv6 то же самое. Подключившись к сети Yggdrasil, вы получаете IPv6-адрес, по которому ваше устройство и все сервисы на нём будут доступны всем, кто подключен к этой же сети... Тут аналогия с локалкой в которой так же всё всем доступно, и ограничениями в которой мало кто озадачивается, ввиду того, что доверия к устройствам в ней больше. Однако, по факту, здесь уже не локалка.
А если вы еще и всем домашним устройствам выдаете адреса из 300::/64, то вся сеть Yggdrasil по умолчанию будет иметь доступ и к вашему телевизору, и к бойлеру, и чайнику, и CCTV...