Публичным пиром сети называется устройство, к которому в оверлейном режиме может подключиться любой желающий. Проще говоря: узел сети, к которому можно подключиться через Интернет и соединиться таким образом с глобальным сегментом сети 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://
.
В версии 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. Не забудьте перезапустить службу 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
Обсуждение
Взято отсюда: https://t.me/Yggdrasil_ru/240678
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/
Раскройте, пожалуйста, вопрос безопасности по данному замечанию:
"Все подключенные пиры будут считаться подключенными локально, будто они с вами в одной локальной сети. Учитывайте это при настройке безопасности."
Как регулярный пользователь, насколько я понимаю:
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 на "внешних" интерфейсах - это очень-очень плохая идея.