Self-hosted ZeroTier-сеть, через которую обеспечивается удалённый доступ ко всем домашним сервисам, без необходимости публиковать SSH/админ-порты в интернет. Контроллер свой, не ZeroTier Central.

• Сеть: c53bc939c1ce37d2 (имя melnoff-main-network), подсеть 172.25.30.0/24.
• Контроллер: zt.melnoff.com (ztnet UI), это не my.zerotier.com. Авторизация участников делается там.
• Свой moon: c53bc939c1 @ 94.103.86.3:9993 (это и есть контроллер). Файл moon: 000000c53bc939c1.moon.
• На каждом новом клиенте — три команды, см. bootstrap_нового_клиента.
• Если ZT «полу-работает» (онлайн, но трафик не ходит) — первым делом проверить allowManaged. См. типичные_проблемы.

1. Planets — публичные корни ZeroTier Inc. Используются для bootstrap. У вас в peers это адреса с ролью PLANET (cafe04eba9, cafe80ed74 и т.п.).
2. Moon (свой) — ваш корень, добавленный к planets. Дублирует функцию rendezvous и даёт быстрый relay внутри РФ.
3. Leaves — обычные клиенты сети. У них роль LEAF.

Контроллер раздаёт клиентам сети (в дополнение к 172.25.30.0/24):

• Зона: homepc.zt
• Резолвер: 192.168.0.11

Push DNS применяется только на клиентах с allowDNS=1.

OpenSSH доступен как ssh root@zt.melnoff.com. На хосте Docker-стек:

⚠️ Версия zerotier-демона 1.14.1 — старая. На клиентах уже 1.16.x. Пока работает, но в долгосрочной перспективе стоит обновить до 1.16.x (для возможного улучшения WHOIS-протокола).

# войти на хост
ssh root@zt.melnoff.com
 
# на хосте — zerotier-cli работает только через docker exec
docker exec zerotier zerotier-cli info
docker exec zerotier zerotier-cli listnetworks
docker exec zerotier zerotier-cli peers
 
# проверить достижимость члена сети с самого контроллера (тест L3)
docker exec zerotier ping -c 3 172.25.30.6
 
# логи
docker logs --tail 100 zerotier
docker logs --tail 100 ztnet
 
# REST API контроллера (через токен из контейнера)
TOK=$(docker exec zerotier cat /var/lib/zerotier-one/authtoken.secret)
docker exec zerotier curl -s -H "X-ZT1-Auth: $TOK" \
  http://localhost:9993/controller/network/c53bc939c1ce37d2/member

• Адрес — на порту 3000 хоста (либо за nginx). Логин/пароль — у владельца.
• Авторизация новых member'ов — там.
• Здесь же редактируются: name, ipAssignments, capabilities/tags, routes, dns push, broadcast, multicast limits.

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

# 1. Установка (Debian/Ubuntu)
curl -s https://install.zerotier.com | sudo bash
 
# 2. Присоединение к сети
sudo zerotier-cli join c53bc939c1ce37d2
 
# 3. Подключить свой moon (важно для symmetric-NAT окружений)
sudo zerotier-cli orbit c53bc939c1 c53bc939c1
 
# 4. Разрешить демону применять выданные IP/маршруты
sudo zerotier-cli set c53bc939c1ce37d2 allowManaged=1
 
# 5. Авторизовать узел в zt.melnoff.com → Members → ✓ Auth

# 1. Установка через Homebrew или из dmg на zerotier.com
brew install --cask zerotier-one
 
# 2-5: те же команды что на Linux. Бинарник в /usr/local/bin/zerotier-cli
sudo zerotier-cli join c53bc939c1ce37d2
sudo zerotier-cli orbit c53bc939c1 c53bc939c1
sudo zerotier-cli set c53bc939c1ce37d2 allowManaged=1

1. Поставить ZeroTier One MSI с zerotier.com.
2. В трее → Join Network → ввести c53bc939c1ce37d2.
3. В админ-cmd: zerotier-cli orbit c53bc939c1 c53bc939c1.
4. Авторизовать узел в Members на zt.melnoff.com.

Положить файл 000000c53bc939c1.moon в:

• Linux: /var/lib/zerotier-one/moons.d/
• macOS: /Library/Application Support/ZeroTier/One/moons.d/
• Windows: %PROGRAMDATA%\ZeroTier\One\moons.d\

После рестарта демона moon будет загружен. zerotier-cli listmoons должен показать его. Это полезно если узел стартует в условиях, когда planet'ы недоступны.

Moon — это ваш собственный root-сервер сети ZeroTier (планета ZT-Inc + ваша «луна» = два корня).

1. Скорость rendezvous и relay. Публичные planet'ы географически далеко (Амстердам, Сингапур, США — latency 150-240 мс). Свой moon в РФ — 8-11 мс. При невозможности hole-punch'а (см. ниже) трафик идёт через корень — на planet'е это медленно.
2. Symmetric-NAT окружения. Если узел за «строгим» NAT'ом (типа корпоративного или мобильного), p2p-соединения не пробиваются. Без relay через близкий moon связь не работает совсем. Конкретный пример в этой сети — узел 172.25.30.6 (cab282198d) за симметричным NAT'ом 193.35.100.225.
3. Независимость от публичной инфраструктуры ZT-Inc. Если planet'ы временно недоступны (блокировка провайдером, DDoS, downtime), свой moon продолжает работать.

• На самом узле-moon (он сам и есть root).
• Если оба пира за обычным cone NAT-ом — hole-punch через planet'ы работает напрямую, moon не используется.

Moon — это подписанный JSON-документ:

{
  "id": "c53bc939c1",
  "roots": [{
    "identity": "c53bc939c1:0:b9b6...<публичный ключ>",
    "stableEndpoints": ["94.103.86.3/9993"]
  }],
  "signature": "...",
  "timestamp": ...,
  "updatesMustBeSignedBy": "..."
}

Создание новой moon: на узле-кандидате zerotier-idtool initmoon /var/lib/zerotier-one/identity.public > moon.json, отредактировать stableEndpoints, потом zerotier-idtool genmoon moon.json → получится .moon. Распространять на клиентов через moons.d/ или команду orbit.

Симптом. zerotier-cli info = ONLINE, listnetworks = OK с правильным IP, peers показывает DIRECT пира — но любой ICMP/TCP до него падает с No route to host или просто таймаутится. Под капотом: ifconfig <ZT iface> не показывает inet-адрес, в netstat -rn нет маршрута на 172.25.30.0/24. Трафик уходит через default route (например, на параллельный VPN).

Причина. Локальная политика клиента запрещает ZT-демону применять IP/маршруты, выданные контроллером.

Лечение.

sudo zerotier-cli set c53bc939c1ce37d2 allowManaged=1

⚠️ leave сети сбрасывает этот флаг в 0. После любого leave/join цикла — выставить заново.

Симптом. Файл .moon в каталоге есть, но zerotier-cli listmoons возвращает [].

Причина. Демон читает moons.d/ только при старте.

Лечение. Без рестарта: sudo zerotier-cli orbit <moonId> <moonId> (для нашей сети — sudo zerotier-cli orbit c53bc939c1 c53bc939c1). С рестартом: sudo launchctl kickstart -k system/com.zerotier.one (macOS) или sudo systemctl restart zerotier-one (Linux).

Симптом. На контроллере (docker exec zerotier zerotier-cli peers) узел виден как DIRECT с low latency. На клиенте этот же узел в peers имеет paths: 0, latency: -1. Пинг не доходит, ARP не resolve'ится.

Причина. Кэш member-info на клиенте залип — endpoint от moon не получен.

Лечение.

sudo zerotier-cli leave c53bc939c1ce37d2
sudo zerotier-cli join c53bc939c1ce37d2
sleep 5
sudo zerotier-cli set c53bc939c1ce37d2 allowManaged=1   # ← обязательно после join

В ZT 1.16 relay-only пути не показываются в массиве paths — поэтому paths: 0 не означает «недоступен», просто «нет p2p». Всегда пробуйте ping реально.

Причина. Узел не авторизован контроллером.

Лечение. На zt.melnoff.com → Members → найти узел по ZT-addr (10 hex) → поставить галку Auth.

Симптом. При ping появляются строчки с пометкой (DUP!).

Причина. На маке параллельно работает второй TUN-VPN (например, AdGuard на utun4 с 198.18.0.1) — он подхватывает копии пакетов.

Лечение. Не критично, на функциональность не влияет. Если раздражает — проверить, не тащит ли VPN-клиент broadcast/multicast в свой туннель.

Делать в этом порядке. Каждый шаг предполагает, что предыдущий вернул «зелёный» результат.

1. Демон ONLINE? sudo zerotier-cli info → ONLINE. Если OFFLINE — UDP 9993 наружу заблокирован, либо демон не запущен.
2. Сеть OK? sudo zerotier-cli listnetworks → OK и осмысленный IP. Если ACCESS_DENIED — авторизовать в Central. Если REQUESTING_CONFIGURATION дольше 30 сек — контроллер недоступен.
3. allowManaged=1? sudo zerotier-cli get <nwid> allowManaged. Если 0 — фиксить (см. проблема №1).
4. Путь до пира. sudo zerotier-cli -j peers → достать запись по ZT-addr целевого узла. Смотреть массив paths. Если пусто — это не обязательно «недоступен» (см. проблема №3), просто нет p2p.
5. Moon загружен? sudo zerotier-cli listmoons → должна быть запись с id = 000000c53bc939c1. Если пусто — orbit (см. проблема №2).
6. Stale member cache? leave/join цикл (см. проблема №3).
7. Последняя надежда: рестарт демона; апгрейд контроллера до ZT 1.16.x.

• Self-hosted controller (ztnet UI)
• Официальная документация ZeroTier
• ztnet (controller UI)
• Где физически живут участники сети