ZeroTier: Побудуйте приватну мережу та вирішіть проблему «Can’t ping»

Що насправді таке ZeroTier (і чого воно не є)

ZeroTier — це оверлейна мережа: вона створює віртуальний інтерфейс, схожий на Ethernet, на кожному вузлі та використовує зашифрований peer-to-peer
транспорт там, де це можливо. Коли peer-to-peer неможливий (строгий NAT, заблокований UDP тощо), воно може ретранслювати трафік.
Думайте про це як «програмно визначений LAN поверх інтернету», хоча на практиці це гібрид:
іноді L2‑подібне, часто L3‑подібне і завжди залежить від реальних умов мережі.

Практичний висновок: коли не виходить ping, рідко справа в тому, що «ZeroTier впало».
Зазвичай це одна з п’яти причин:
авторизація, адресація, політика брандмауера ОС, маршрутизація/перекриття або MTU/фрагментація.
Далі в статті — як швидко довести, яка саме.

Чого ZeroTier не є: воно не є магічним обхідником корпоративної еґрес‑політики і не замінює розуміння маршрутів.
Також воно не змусить Windows‑хост відповідати на ICMP, якщо Windows Firewall каже «ні».
Якщо ви читаєте це через «вказує ONLINE, але я не можу зробити ping», ласкаво просимо до клубу.

Факти та контекст, які спрощують діагностику

Деяка історія та механіка важливі, бо пояснюють режими відмов. Ось дев’ять конкретних пунктів, які варто знати.

1. ZeroTier за замовчуванням використовує UDP (зазвичай порт 9993). Якщо egress для UDP заблокований, ви можете отримати ретрансляцію або взагалі відсутність звʼязку.
2. У вузлів є 10‑значна ідентичність, отримана з криптографічних ключів. Ця ідентичність зберігається; зміна IP не змінює ідентифікатор вузла.
3. Мережі ідентифікуються 16‑значним ID мережі. Приєднання до невірної мережі — класична помилка «все виглядає добре».
4. “ONLINE” не означає “доступно”. Часто це означає «контролер знає про цей вузол», а не «ICMP працюватиме наскрізь».
5. Прямий peer‑to‑peer — опортуністичний. NAT traversal або вдається, або ні, залежно від реальної поведінки NAT, підтримки hairpin і мапування портів.
6. Ретрансляції — нормальна річ. Коли ви бачите “RELAY”, латентність зростає, а пропускна здатність падає. Це може ламати застосунки, чутливі до RTT або MTU.
7. Керовані маршрути — це політика на боці контролера. Якщо ви очікуєте site‑to‑site звʼязок без оголошення маршрутів, вас регулярно чекатимуть розчарування.
8. Бриджинг потужний, але ризиковий. Бриджинг може перетворити чистий оверлей на «вечірку широкомовлення». Добре в деяких старих кейсах, жахливо для «чому так повільно?»
9. Перекриття підмереж — отрута. Якщо ваша мережа ZeroTier використовує 192.168.1.0/24, а у когось вдома такий самий діапазон, пакети підуть найгіршим можливим шляхом.

Побудуйте приватну мережу, яка поводиться передбачувано

Виберіть план адресації, що не конфліктуватиме з реальністю

Не обирайте 192.168.0.0/24 або 10.0.0.0/24, якщо ваше хобі — дебаг split‑brain маршрутизації.
Використовуйте щось банальне й малоймовірне: виділену частину 10/8 (але не звичні підсітки), або, якщо ваша інфраструктура дозволяє,
використовуйте IPv6 всередині ZeroTier.

Простий варіант із низьким ризиком перекриття: 10.147.0.0/16 для оверлею, а потім вирізайте /24, якщо пізніше будете бриджувати сайти.
Точний діапазон не має значення; важливе — відсутність перекриттів.

Вирішіть: маршрутизація чи бриджинг (не робіть «трохи те, трохи інше»)

Для site‑to‑site підключень майже завжди правильний вибір — маршрутизація. Бриджинг призначений для випадків, коли вам справді потрібна L2‑сусідність
(якийсь старий discovery‑протокол, припущення немаршрутизованого застосунку або пристрій від постачальника, який «не любить» маршрутизатори).

Бриджинг збільшує зону ураження. Широкомовлення й мультикаст можуть розлитися в оверлей, і саме так з’являються дивні стрибки затримки.
Якщо ваша мета — «підключитися по SSH до серверів і дістати кілька підмереж», маршрутизуйте.

Контрольна площина vs площина даних: авторизація не опціональна

Приватна мережа вимагає авторизації учасників. Якщо забути авторизувати, вузол може зʼявитися, але трафік не пропускатиме.
Це не тонка проблема; це «я клянусь, він підключений» проблема.

Встановіть базу: ping — не перший тест

ICMP корисний, але його часто блокують. Ваш перший базовий тест повинен бути:
(1) чи вузли бачать одне одного як peers, та (2) чи можна пропустити TCP на відомий відкритий порт (SSH, HTTPS або тимчасовий netcat‑лістенер).

Жарт №1: Ping — як пожежний датчик: коли він мовчить, або ви в безпеці, або батарейка сіла кілька місяців тому й ніхто не попередив.

Швидка діагностика — план дій (перевіряйте в цьому порядку)

Коли ви на виклику, вам не нараховують балів за креативність. Вам нараховують бали за швидкість і впевненість.
Ось порядок, який знаходить вузьке місце з найменшими метушнями.

1) Підтвердьте членство й авторизацію

• Вузол приєднано до правильного network ID?
• Він авторизований на контролері?
• Чи має він призначену IP на ZeroTier?

2) Перевірте локальний інтерфейс і маршрути

• Чи існує інтерфейс ZeroTier і чи має він IP?
• Чи таблиця маршрутів відправляє трафік на інтерфейс ZeroTier, а не на неправильний шлюз через перекриття?

3) Перевірте якість шляху до peer (DIRECT vs RELAY) та доступність UDP

• Peers — “DIRECT” чи “RELAY”?
• Чи заблокований UDP 9993 на вихід чи вхід?
• Чи знаходитеся ви за symmetric NAT, що вбиває P2P?

4) Перевірте брандмауери хостів і політику ICMP

• Чи дозволяє брандмауер ОС ICMP та потрібні TCP‑порти на ціль?
• Чи відрізняється політика для профілів «Public» vs «Private» (Windows)?

5) Перевірте MTU/фрагментацію, коли маленькі пакети працюють, а великі — ні

• Чи можна ping з маленьким payload, але не з великим?
• Чи бачите ви PMTUD‑чорні діри через блоковані ICMP fragmentation‑needed?

6) Тільки потім: ускладнюйте

• Бриджингові петлі, помилки конфігурації керованих маршрутів, політика маршрутизації, особливості неймспейсу контейнерів, moons тощо.

Практичні завдання: команди, виводи та рішення

Наступні завдання навмисне операційні. Кожне містить команду, реалістичний вивід, що це означає,
та наступне рішення, яке слід ухвалити. Виконуйте їх на обох кінцях (джерело і призначення), якщо завдання не явно для контролера.

Завдання 1: Перевірте, що сервіс ZeroTier запущений (Linux systemd)

cr0x@server:~$ systemctl status zerotier-one --no-pager
● zerotier-one.service - ZeroTier One
     Loaded: loaded (/lib/systemd/system/zerotier-one.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2025-12-27 09:11:42 UTC; 2h 13min ago
   Main PID: 1178 (zerotier-one)
      Tasks: 24 (limit: 19070)
     Memory: 38.6M
        CPU: 1min 22.413s
     CGroup: /system.slice/zerotier-one.service
             └─1178 /usr/sbin/zerotier-one

Значення: Демон живий. Якщо він inactive/failed — інші речі не мають значення.

Рішення: Якщо не запущений, запустіть і перевірте логи перед тим, як чіпати маршрути/брандмауери.

Завдання 2: Підтвердьте, що ви приєдналися до потрібного network ID

cr0x@server:~$ sudo zerotier-cli listnetworks
200 listnetworks <nwid> <name> <mac> <status> <type> <dev> <ZT assigned ips>
200 listnetworks a84ac5c10a1b2c3d corp-overlay 5e:33:aa:9d:01:10 OK PRIVATE zt7nn3p3kq 10.147.10.23/16

Значення: Ви приєднані, статус OK, і маєте призначений IP в оверлеї.

Рішення: Якщо статус ACCESS_DENIED або немає призначеного IP — спочатку виправте авторизацію або налаштування IP.

Завдання 3: Перевірте ідентичність вузла (корисно для авторизації на контролері)

cr0x@server:~$ sudo zerotier-cli info
200 info 9f3c1a2b3c 1.14.2 ONLINE

Значення: ID вузла — 9f3c1a2b3c. Ви використаєте його на контролері для авторизації та звірки членства.

Рішення: Якщо він не ONLINE, можливі проблеми з UDP reachability, DNS або розходження часу, що викликає проблеми довіри.

Завдання 4: Перелічіть peers і подивіться DIRECT vs RELAY

cr0x@server:~$ sudo zerotier-cli listpeers
200 listpeers <ztaddr> <path> <latency> <version> <role>
200 listpeers 62f865ae71 203.0.113.19/9993;2684 34 1.14.2 LEAF
200 listpeers 9d219039f7 198.51.100.8/9993;58421 41 1.14.2 LEAF
200 listpeers 35c192ce9b - 0 1.14.2 PLANET

Значення: У вас є прямі шляхи до peers (показано публічну IP/порт). Якщо ви бачите RELAY або дефіс у полі path — очікуйте проблем.

Рішення: Якщо ретрансляція і вам важлива продуктивність — діагностуйте NAT/UDP або додайте moon у досяжне місце.

Завдання 5: Підтвердіть інтерфейс ZeroTier і IP‑адресу

cr0x@server:~$ ip -brief addr show | grep -E 'zt|zerotier'
zt7nn3p3kq         UP             10.147.10.23/16 fe80::5c33:aaff:fe9d:110/64

Значення: Інтерфейс існує, він UP і має очікувану адресу оверлею.

Рішення: Якщо інтерфейс відсутній/виключений — ймовірно, join не пройшов або сервіс не запущено.

Завдання 6: Перевірте таблицю маршрутів на предмет перекриття або неправильного next hop

cr0x@server:~$ ip route show
default via 192.168.50.1 dev eth0
10.147.0.0/16 dev zt7nn3p3kq proto kernel scope link src 10.147.10.23
192.168.50.0/24 dev eth0 proto kernel scope link src 192.168.50.20

Значення: Підмережа оверлею направлена на інтерфейс ZeroTier. Добре.

Рішення: Якщо підмережа перекривається з локальною — ви побачите конфлікт маршрутів. Виправляйте план адресації або використовуйте керовані маршрути обережно.

Завдання 7: Спробуйте TCP‑зʼєднання замість ping (netcat)

cr0x@server:~$ nc -vz 10.147.10.50 22
Connection to 10.147.10.50 22 port [tcp/ssh] succeeded!

Значення: Навіть якщо ping не працює, TCP працює. Часто це означає, що ICMP заблоковано, а не що ZeroTier зламався.

Рішення: Перестаньте витрачати час на ping. Виправте політику брандмауера, якщо вам справді потрібен ICMP; інакше працюйте з вашим застосунком.

Завдання 8: Підтвердіть, що ICMP локально заблокований (Linux брандмауер: nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    iifname "zt7nn3p3kq" tcp dport { 22, 443 } accept
  }
}

Значення: За замовчуванням input — drop, і на інтерфейсі ZeroTier дозволені лише TCP 22/443. ICMP не дозволено.

Рішення: Додайте явний accept для ICMP на інтерфейсі ZeroTier, якщо потрібен ping, або задокументуйте «ping не працюватиме» і рухайтеся далі.

Завдання 9: Перевірте невідповідність профілю брандмауера Windows (PowerShell)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetConnectionProfile | Format-Table Name,InterfaceAlias,NetworkCategory"
Name              InterfaceAlias           NetworkCategory
corp-wifi          Wi-Fi                    Public
ZeroTier One [a84ac5c10a1b2c3d]  ZeroTier One Virtual Port Private

Значення: Інтерфейс ZeroTier має профіль “Private”, але інші інтерфейси можуть бути “Public”. Правила можуть не застосовуватися там, де ви думаєте.

Рішення: Переконайтеся, що вхідні правила привʼязані до інтерфейсу ZeroTier або до правильного профілю; не припускайте, що «Private» автоматично означає «дозволено».

Завдання 10: Швидкий тест MTU (Linux ping з DF)

cr0x@server:~$ ping -c 2 -M do -s 1472 10.147.10.50
PING 10.147.10.50 (10.147.10.50) 1472(1500) bytes of data.
ping: local error: message too long, mtu=280
ping: local error: message too long, mtu=280

--- 10.147.10.50 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1015ms

Значення: Path MTU значно менший за Ethernet 1500. Щось інкапсулює всередині іншої інкапсуляції (часто VPN‑на‑VPN, PPPoE або блоковане PMTUD).

Рішення: Зменшіть MTU ZeroTier (або виправте підлягаючий шлях) і перевіряйте з меншими розмірами пакету, доки тест не пройде.

Завдання 11: Перегляньте локальну конфігурацію ZeroTier і директорію networks

cr0x@server:~$ sudo ls -al /var/lib/zerotier-one
total 64
drwxr-xr-x  5 root root  4096 Dec 27 09:11 .
drwxr-xr-x 38 root root  4096 Dec 27 09:11 ..
-rw-r--r--  1 root root    64 Dec 27 09:11 identity.public
-rw-------  1 root root   256 Dec 27 09:11 identity.secret
drwxr-xr-x  2 root root  4096 Dec 27 09:11 networks.d
-rw-r--r--  1 root root  1254 Dec 27 09:11 zerotier-one.port

Значення: Ідентичність існує; конфіги членства зберігаються в networks.d.

Рішення: Якщо файли ідентичності відсутні або права доступу неправильні, ідентичність вузла зміниться або демон працюватиме дивно. Виправте файлову систему/права перед налаштуванням мережі.

Завдання 12: Перевірте доступність UDP 9993 з мережі хоста

cr0x@server:~$ sudo ss -uapn | grep 9993
UNCONN 0      0          0.0.0.0:9993      0.0.0.0:*    users:(("zerotier-one",pid=1178,fd=25))
UNCONN 0      0             [::]:9993         [::]:*    users:(("zerotier-one",pid=1178,fd=26))

Значення: ZeroTier слухає UDP 9993. Це необхідно, але недостатньо.

Рішення: Якщо не слухає — перевірте конфіг або чи демон зв’язаний правильно. Якщо слухає, але peers все одно через ретрансляцію, підозрюйте upstream брандмауер/NAT.

Завдання 13: Швидкий захоп трафіку на інтерфейсі ZeroTier

cr0x@server:~$ sudo tcpdump -ni zt7nn3p3kq icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on zt7nn3p3kq, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:45:11.203812 IP 10.147.10.23 > 10.147.10.50: ICMP echo request, id 1789, seq 1, length 64
10:45:12.210914 IP 10.147.10.23 > 10.147.10.50: ICMP echo request, id 1789, seq 2, length 64

Значення: Запити виходять. Якщо ви не бачите відповідей, проблема нижче по шляху: брандмауер призначення, маршрут назад або втрата пакетів.

Рішення: Запустіть tcpdump і на приймальній стороні. Якщо приймач не бачить запитів — проблема в маршрутизації/шляху ZeroTier. Якщо бачить і не відповідає — це політика хоста.

Завдання 14: Перевірте зворотній шлях і пастки політики маршрутизації

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.zt7nn3p3kq.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.zt7nn3p3kq.rp_filter = 1

Значення: Увімкнено строгий reverse path filtering. На multi‑homed хостах це може відкидати валідний трафік, якщо ядро вважає шлях назад «неправильним».

Рішення: Якщо ви маршрутизуєте між інтерфейсами або використовуєте policy routing, подумайте про встановлення rp_filter в loose (2) на відповідних інтерфейсах.

Завдання 15: Перевірте IP‑форвардинг, якщо цей вузол має маршрутизувати трафік

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Значення: Цей хост не маршрутизуватиме пакети між інтерфейсами.

Рішення: Якщо ця машина — ваш шлюз ZeroTier для site‑to‑site маршруту, увімкніть форвардинг і додайте firewall‑правила для форвардингу/NAT за потреби.

Завдання 16: Перевірте перекриття підмереж, що «викрадає» трафік (класичне «can’t ping»)

cr0x@server:~$ ip route get 10.147.10.50
10.147.10.50 dev zt7nn3p3kq src 10.147.10.23 uid 1000
    cache

Значення: Ядро відправить трафік через інтерфейс ZeroTier. Якщо воно обрало б eth0, у вас перекриття або більш специфічний маршрут.

Рішення: Виправте план адресації або пріоритет маршрутів. Не «працюйте навколо» перекриття хаками, якщо ви не любите повторювані інциденти.

Детальний розбір «can’t ping»: де гинуть пакети

Зона відмов 1: Ви фактично не авторизовані (або приєдналися до невірної мережі)

Контролер — це охоронець. Якщо вас не «погашено», вас не впустять.
Вузол може зʼявлятися в списку членів, але залишатися неавторизованим. Залежно від UI/політик контролера, ви все одно можете бачити індикатори «connected»,
які вводять в оману.

Операційне правило: вважайте за реальне членство «має ZeroTier IP і може обмінюватися пакетами», а не «я бачу його в веб‑UI».

Зона відмов 2: ICMP заблоковано, і ви женетеся за не тією проблемою

Ping — це ICMP echo. Багато середовищ за замовчуванням блокують ICMP inbound, особливо Windows‑хости і захищені Linux‑сервери.
Якщо SSH працює, а ping — ні, це не «ZeroTier не може ping»; це «ICMP заблоковано».

Якщо ваш моніторинг використовує ping, або дозвольте його явно на інтерфейсі ZeroTier, або переключіть моніторинг на TCP‑перевірки.
TCP‑перевірки зазвичай ближчі до того, що вас цікавить: застосунок.

Зона відмов 3: Асиметрія маршрутів і «повернення йде кудись іще»

Оверлейні мережі все ще залежать від рішень маршрутизації. Якщо хост A відправляє пакети до хоста B по ZeroTier,
хост B має відправити відповіді назад через ZeroTier (або принаймні таким чином, щоб A зрозумів відповідь).
Якщо хост B вважає, що A знаходиться на іншому інтерфейсі через перекриття або policy routing, відповіді губляться.

Це проявляється так: tcpdump на A показує вихідні echo request, tcpdump на B показує їх прибуття,
але B ніколи не відповідає (або відповідає через неправильний інтерфейс). Reverse path filtering також може скидати ці відповіді.

Зона відмов 4: Перекриття підмереж з домашніми/офісними мережами

Перекриття — мовчазний вбивця, бо воно непостійне. Ваш офіс може використовувати 10.0.0.0/8 широко,
ви в оверлеї обрали 10.0.0.0/24, а локальна мережа віддаленого користувача випадково збігається.
Деякі машини працюють, деякі ні, і ви починаєте звинувачувати ZeroTier, наче воно привид.

Виправте перекриття, вибравши виділений діапазон оверлею і дотримуючись його. Якщо перекриття вже розгорнуто,
мігруйте планово й в одному напрямку. «Тимчасові» перекриваючі маршрути — шлях до постійного хаосу.

Зона відмов 5: NAT traversal vs ретрансляції (DIRECT має значення)

Коли NAT traversal проходить, peers говорять напряму. Коли ні — вони можуть ретранслювати через інфраструктуру.
Ретрансляції підходять для адміністрування; вони можуть бити по продуктивності при передачі великих обсягів, базах даних і всьому, що чутливе до тайм‑аутів.
Іноді ping працює, але ваш застосунок таймаутиться через затримку та джиттер ретрансляції.

Ви можете часто покращити пряме зʼєднання, дозволивши UDP outbound, переконавшись, що мережеві «UDP helper» не псують пакети,
або розмістивши moon у доступному для обох боків місці.

Зона відмов 6: MTU і PMTUD‑чорні діри

Ви помітите це, коли «маленьке працює, а велике ламається». Можливо, ping працює з дефолтним розміром, але не з великими payload,
або SSH підключається, але передачі файлів зависають, або TLS‑рукопотискання зависає дивно.

Інкапсуляція оверлею додає оверхед. Якщо підлягаючий шлях має зменшений MTU (PPPoE, мобільні мережі, вкладені тунелі),
ви можете його перевищити. Коректний PMTUD вимагає ICMP «fragmentation needed», багато мереж їх блокують і створюють чорну діру.

Зона відмов 7: Бриджинг і широкомовні шторми (або просто галасна мережа)

Бриджинг може зробити «can’t ping» схожим на «іноді ping, іноді ні», бо ви ввели L2‑шум.
Широкомовлення й мультикаст можуть забити корисний трафік, особливо на обмежених лінках.
Зазвичай виправлення — припинити бриджинг і маршрутизувати.

Цитата про надійність, бо вона пасує

«Надія — не стратегія.» — генерал Гордон Р. Салліван

В операціях це означає: припиніть сподіватися, що ping почне працювати, і почніть збирати докази шарами.

Жарт №2: NAT — це корпоративний middle manager мереж: він додає зустрічі, губить повідомлення і все одно забирає собі лаври, коли щось працює.

Три корпоративні історії з реального життя

Міні‑історія 1: Інцидент через неправильне припущення

Середня компанія розгорнула ZeroTier, щоб підключити декілька адмінських робочих станцій до тестових серверів у лабораторії.
Розробник сказав: «Як тільки показує ONLINE — ми можемо пінгувати все». Це припущення потрапило прямо в рунабоок.
Моніторинг будували на ping, бо це було просто і виглядало як мережевий тест.

Першого ж вікенду Windows jump host оновили й перезавантажили. Він повернувся в контролері як ONLINE.
Перевірки ping провалилися. Сигнали тривоги. На чергуванні годину гонялися за peers і NAT traversal.
Врешті хтось спробував nc до порту 3389 — і воно спрацювало. RDP працював. Лише ping не працював.

Корінь проблеми: брандмауер Windows після зміни профілю повернув більш сувору політику inbound ICMP на адаптері ZeroTier.
Система моніторингу інтерпретувала «немає ICMP» як «хост недоступний», а звіт про інцидент звинуватив оверлей.
Оверлей виявився невинним; винне — припущення.

Виправлення було нудне й ефективне: змінити моніторинг на TCP‑перевірки для реального сервісу (RDP/SSH/HTTPS),
і явно дозволити ICMP лише там, де це необхідно. Рунадбук оновили фразою «ONLINE — не означає доступність».
Це одне речення зберегло кілька субот у майбутньому.

Міні‑історія 2: Оптимізація, яка відкинулася бумерангом

Інша організація захотіла «кращу продуктивність» через ZeroTier і вирішила здійснити бридж двох офісних LAN у оверлей.
Аргумент звучав логічно: «Якщо це один великий LAN, discovery‑протоколи спрацюють і застосунки не потрібно буде міняти».
Вони ввімкнули бридж на парі Linux‑шлюзів і по‑перше святкували кілька вдалих ping.

До понеділка поскаржилися: відеодзвінки гальмували, файлообміни зупинялися, а випадкові пристрої на одній локації почали показувати дубльовані IP.
Служба підтримки звинувачувала ISP. Неткоманда — Wi‑Fi.
SRE зробив немодний крок: захопив трафік на інтерфейсі ZeroTier і порахував broadcast‑фрейми.

Виявилося, що вони фактично розширили broadcast‑домен через інтернет‑оверлей з мінливими затримками й джиттером,
і тягнули багато «балакучого» L2‑трафіку (включно з тим, що ніколи не мав покидати будівлю) через нього.
Деякі пристрої не справлялися з новою «локальною» топологією. ARP поводився дивно. DHCP‑широкомовлення перетворилося на кошмар.

Вони негайно відкотили зміни. Замінили бриджинг на маршрутизацію, додали кілька керованих маршрутів для потрібних підмереж
і використовували конфігурацію на рівні застосунків для discovery, де можливо.
Продуктивність покращилася, бо вони перестали намагатися змусити інтернет поводитися як свіч.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Регульована компанія використовувала ZeroTier для невеликого внутрішнього фліту build‑агентів, розкиданих по різних провайдерах.
Вони ставилися до оверлею як до продакшен‑мережі: послідовний план адресації, документовані керовані маршрути
і стандартна базова політика брандмауера хостів, яка явно дозволяла потрібні порти на інтерфейсі ZeroTier.
Ніяких героїчних рішень, ніяких «ми потім згадамо».

Одного дня провайдер змінив щось у своєму мережевому шляху і підмножина вузлів почала ретранслюватися.
Затримка зросла; деякі збірки почали таймаутитися при завантаженні артефактів. Ніхто не панікував.
Черговий дотримувався того самого чек‑лісту щоразу: peers (DIRECT vs RELAY), таблиці маршрутів, потім MTU‑тести.

Вони знайшли проблему PMTUD на шляху одного з провайдерів. Оскільки їхня базова процедура включала MTU‑валідацію і документований регулятор
для зниження MTU на уражених вузлах, вони розгорнули тимчасово менший MTU для вузлів цього провайдера, поки ескалували upstream.
Збірки стабілізувалися за годину. Ніякої конференції інциденту не знадобилося.

Урок: нудні дефолти й відтворювані перевірки — це фіча продуктивності. Вони зменшують час до істини.
У продакшені саме це вам і потрібно.

Типові помилки: симптом → корінь → виправлення

1) Симптом: «Вузол показує ONLINE, але не має ZeroTier IP»

Корінь: Член не авторизований, auto‑assign IP вимкнено або вузол приєднався до невірного network ID.

Виправлення: Авторизуйте учасника і переконайтеся, що мережа має пул IPv4/IPv6. Повторно перевірте zerotier-cli listnetworks.

2) Симптом: «Ping не працює, SSH працює»

Корінь: ICMP заблоковано брандмауером хоста або політикою ОС.

Виправлення: Дозвольте ICMP на інтерфейсі/профілі ZeroTier або перестаньте використовувати ping як основну перевірку доступності.

3) Симптом: «Можу пінгувати по ZeroTier IP, але не можу дістатися віддаленої LAN‑підмережі»

Корінь: Відсутній керований маршрут, відключений IP‑форвардинг або відсутні правила NAT/forwarding на шлюзі.

Виправлення: Додайте керовані маршрути на контролері; увімкніть net.ipv4.ip_forward=1; додайте правила форвардингу (і NAT, якщо потрібно).

4) Симптом: «Дехто може пінгувати, дехто — ні (особливо з дому)»

Корінь: Перекриття підмереж з домашніми роутерами або split DNS, що відправляє трафік невірним шляхом.

Виправлення: Змініть підмережу оверлею на діапазон з низьким ризиком конфліктів; уникайте звичних RFC1918 діапазонів; перевірте ip route get.

5) Симптом: «Інтермітентні втрати пакетів, джиттер, ‘RELAY’ peers»

Корінь: Зрив NAT traversal або блокування UDP; трафік йде через ретрансляцію.

Виправлення: Дозвольте UDP outbound; уникайте обмежувальних egress‑мереж; розгляньте moon в досяжній зоні; повторно перевірте listpeers.

6) Симптом: «Малі запити працюють; великі передачі зависають»

Корінь: MTU/PMTUD‑чорна діра; десь блоковано ICMP fragmentation‑needed.

Виправлення: Зменшіть MTU на інтерфейсі оверлею і/або виправте обробку ICMP upstream; валідируйте за допомогою ping -M do.

7) Симптом: «Після ввімкнення бриджингу все стало дивним і повільним»

Корінь: Посилення широкомовлення/мультикасту через оверлей; ненавмисне розширення L2.

Виправлення: Припиніть бриджинг; маршрутизируйте; звузьте дозволений трафік і підмережі; переконайтеся, що вам справді потрібен L2.

8) Симптом: «Працює, доки не запускаємо контейнери»

Корінь: Неймспейси мережі контейнерів і правила брандмауера не враховують інтерфейс ZeroTier; асиметрична маршрутизація через docker0.

Виправлення: Вирішіть, чи контейнери повинні привʼязуватися до ZeroTier IP хоста, або запускайте окремі правила маршрутизації/NAT для підмереж контейнерів.

Контрольні списки / покроковий план

Чек‑лист A: Розгортання нової мережі ZeroTier (мала організація)

1. Виберіть підмережу оверлею, що не перекриватиметься з офісними/домашніми діапазонами (уникайте 192.168.0.0/16 і поширених 10.0.0.0/24).
2. Вирішіть: маршрутизація чи бриджинг. За замовчуванням — маршрутизація.
3. Приєднайте 2–3 пілотні вузли і авторизуйте їх.
4. Переконайтеся, що zerotier-cli listnetworks показує OK і призначені IP.
5. Перевірте, що zerotier-cli listpeers показує прямі шляхи, де це можливо.
6. Визначте політику брандмауера хоста: дозволяйте лише потрібні порти на інтерфейсі ZeroTier.
7. Виберіть реальний тест доступності: TCP до порту сервісу, плюс ping тільки якщо ви явно дозволите ICMP.
8. Документуйте керовані маршрути та відповідальних за них (хто додає маршрути, хто погоджує).
9. Запустіть MTU‑валідацію і зафіксуйте базовий робочий розмір payload.

Чек‑лист B: Site‑to‑site підключення (маршрутизація віддаленої підмережі через ZeroTier)

1. Виберіть gateway‑вузол на віддаленому сайті з стабільним аптаймом і відомою власністю брандмауера.
2. Увімкніть IP‑форвардинг на шлюзі (net.ipv4.ip_forward=1).
3. Додайте керований маршрут для віддаленої підмережі, що вказує на ZeroTier IP шлюзу.
4. Переконайтеся, що віддалена LAN‑підмережа має маршрут відповіді назад в оверлей (через шлюз або NAT).
5. Перевірте послідовно: хост → ZeroTier IP шлюзу → віддалений LAN IP.
6. Заблокуйте правила форвардингу так, щоб оверлей дістався лише до того, що потрібно.

Чек‑лист C: Інцидент «Can’t ping»

1. Підтвердьте join мережі + авторизацію (Завдання 2).
2. Підтвердьте, що інтерфейс UP + IP в оверлеї (Завдання 5).
3. Перевірте вибір маршруту (Завдання 6 і Завдання 16).
4. Перевірте шлях до peer (Завдання 4).
5. Спробуйте TCP на відомий порт (Завдання 7).
6. Перевірте правила брандмауера хоста (Завдання 8 / перевірки профілів Windows).
7. Захопіть трафік на обох кінцях (Завдання 13), щоб побачити, чи запити доходять і чи відповіді виходять.
8. Якщо симптоми вказують — зробіть MTU‑тест (Завдання 10).
9. Тільки потім ескалюйте до moons/бриджинг/змін політики маршрутизації.

FAQ

1) Чому ZeroTier показує “ONLINE”, а я не можу пінгувати?

“ONLINE” не гарантує ICMP‑доступності. Поширені причини: член не авторизований, ICMP заблоковано брандмауером хоста,
перекриття підмереж або асиметрія маршрутів. Використовуйте TCP‑тести і захоп трафіку, щоб довести, де пакети зупиняються.

2) Чи обовʼязково використовувати ping, щоб довести, що ZeroTier працює?

Ні. Ping тестує ICMP echo; багато систем його блокують. Кращий тест «чи працює» — TCP до відомого відкритого порту
або health‑check на рівні застосунку. Дозволяйте ICMP тільки якщо маєте явну операційну потребу.

3) Що означає DIRECT vs RELAY у listpeers?

DIRECT означає, що peers знайшли peer‑to‑peer шлях (звичайно краща латентність та пропускна здатність). RELAY означає, що трафік проходить через ретранслятор
через невдачу NAT traversal або блокування UDP. RELAY підходить для адміністрування, але гірший для великого трафіку.

4) Яку підмережу обрати для моєї мережі ZeroTier?

Використовуйте підмережу, яка не перекриватиметься з реальними мережами, де будуть користувачі. Уникайте поширених домашніх/SMB‑діапазонів.
Виберіть щось малоймовірне в 10/8 або використайте IPv6. Послідовність важливіша за «кмітливість».

5) Як працюють керовані маршрути?

Керовані маршрути кажуть членам ZeroTier: «щоб дістатися цієї підмережі, надсилайте трафік цьому члену як шлюзу».
Вони не вмикають форвардинг автоматично; ваш шлюз має мати IP‑форвардинг і брандмауерні правила для форвардингу трафіку.

6) Чи потрібен мені moon?

Не завжди. Moon допомагає, коли багато вузлів за суворим NAT або коли потрібна передбачувана досяжність.
Якщо більшість peers в RELAY і продуктивність важлива, moon у досяжному середовищі вартий розгляду.

7) Чому SSH підключається, але передача файлів зависає?

Така поведінка часто вказує на MTU/PMTUD. SSH може встановити сесію з маленькими пакетами, а потім зависнути, коли більші пакети або інші сегменти TCP перевищать MTU‑чорну діру.
Протестуйте з ping -M do і зменшіть MTU, якщо потрібно.

8) Чи можна бриджувати мій LAN у ZeroTier?

Можна, але, ймовірно, не варто. Бриджинг розширює L2‑broadcast домени і може спричинити шумний трафік,
дивну поведінку ARP/DHCP і проблеми з продуктивністю. Маршрутуйте, якщо у вас немає вагомої L2‑потреби, яку ви можете обґрунтувати в постмортемі.

9) Чому я не можу дістатися пристрою в віддаленій LAN з клієнта ZeroTier?

Зазвичай відсутній шлях відповіді. Ви додали керований маршрут, але пристрій у віддаленій LAN не знає, як відповісти на підмережу оверлею.
Виправте це через маршрут повернення на LAN‑маршрутизаторі або через NAT на шлюзі (усвідомлюючи наслідки для аудиту й дебагу).

10) Чи завжди потрібен UDP 9993?

Поведінка ZeroTier зазвичай спирається на UDP. Якщо UDP заблокований, ви можете отримати деграду в звʼязності або її відсутність.
Іноді можна обходитись ретрансляціями, але якщо мережа блокує широкий outbound UDP, очікуйте проблем.

Наступні кроки, які ви можете зробити сьогодні

1. Припиніть вважати ping єдиним джерелом істини. Визначте, що означає «up» для вашого сервісу, і тестуйте це.
2. Стандартизуйте план адресації оверлею. Якщо вже є перекриття — заплануйте міграцію першими, а не тоді, коли вона призначить вас.
3. Зафіксуйте стан peer‑health. Записуйте, скільки peers є DIRECT vs RELAY у нормальних умовах.
4. Запишіть порядок «Швидкої діагностики». Помістіть його в on‑call runbook, а не в чиїсь голови.
5. Зробіть політику брандмауера явною. Дозвольте те, що потрібно на інтерфейсі ZeroTier; забороніть решту; документуйте наміри.
6. Додайте MTU‑тест у свій інструментарій. Більшість команд виявляють MTU‑проблеми лише після того, як втратять день. Будьте розумнішими.

Якщо ви зробите ці шість речей, «can’t ping» перетвориться на проблему класифікації за дві хвилини, а не на тригодинну спіраль звинувачень.
Це різниця між акуратним оверлеєм і дорогим хобі.