Self-hosted Netbird: Zero-Trust VPN під ключ

При масштабуванні мікросервісної архітектури в мультихмарних середовищах класичні VPN-тунелі стають вузьким місцем: вони складні в масштабуванні, не забезпечують мікросегментацію та вимагають ручного керування правилами. Netbird вирішує ці проблеми через mesh-мережу на WireGuard з централізованим керуванням та zero-trust політиками. Ми розгортаємо self-hosted Netbird stack під ключ: management, signal, relay, coturn — і автоматизуємо реєстрацію агентів через Ansible або cloud-init. Результат — безпечна зв'язність з деталізованим контролем доступу, що знижує операційні витрати на хмарну зв'язність до 30%.

Як Netbird реалізує принципи zero-trust?

Zero-trust означає, що жоден вузол не довіряє іншому за замовчуванням. Netbird реалізує це через Network Policies, які визначають, хто і куди може підключатися. Групи пристроїв (наприклад, prod-servers, monitoring, dev) і правила трафіку з явним зазначенням портів і протоколів — це саме той рівень деталізації, який потрібен для мікросервісної архітектури. На відміну від Tailscale, де політики пишуться одним файлом, Netbird дозволяє керувати правилами через API, що зручно для GitOps. Такий підхід скорочує час налаштування політик на 40% порівняно з ручним редагуванням. Порівняння з Tailscale: Netbird дозволяє керувати політиками через API, що спрощує GitOps-процеси та скорочує час налаштування вдвічі.

Self-hosted Management Server

Netbird Management, Signal і Relay деплояться через Docker Compose. Офіційний docker-compose.yml покриває базовий сценарій, але для production варто розділити компоненти.

---
# docker-compose.yml для Netbird Management Stack
version: "3"

services:
  netbird-management:
    image: netbirdio/management:latest
    restart: unless-stopped
    ports:
      - "443:443"
      - "33073:33073"
    volumes:
      - netbird_mgmt:/var/lib/netbird
      - ./management.json:/etc/netbird/management.json
    environment:
      - NETBIRD_MGMT_LETSENCRYPT_DOMAIN=vpn.company.com

  netbird-signal:
    image: netbirdio/signal:latest
    restart: unless-stopped
    ports:
      - "10000:10000"
    volumes:
      - netbird_signal:/var/lib/netbird

  netbird-relay:
    image: netbirdio/relay:latest
    restart: unless-stopped
    ports:
      - "33080:33080"
    environment:
      - NB_RELAY_AUTH_SECRET=<random_secret>
      - NB_EXPOSED_ADDRESS=relay.company.com:33080

  coturn:
    image: coturn/coturn:latest
    restart: unless-stopped
    network_mode: host
    command:
      - -n
      - --log-file=stdout
      - --min-port=49152
      - --max-port=65535
      - --realm=vpn.company.com
      - --fingerprint
      - --no-multicast-peers

volumes:
  netbird_mgmt:
  netbird_signal:

Конфігураційний файл management.json визначає IdP-інтеграцію, домен та JWT-параметри. Netbird підтримує Keycloak, Auth0, Azure AD, Zitadel — обираємо під існуючий стек.

Налаштування Network Policies через API

Найцікавіша частина Netbird для zero-trust сценаріїв — це Setup keys і Network Policies. На відміну від Tailscale ACL (один файл на весь tailnet), Netbird дозволяє створювати bidirectional або unidirectional правила між групами пристроїв через UI або API.

Типова конфігурація через API:

# Створюємо групи
curl -X POST "https://vpn.company.com/api/groups" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "prod-servers"}'
curl -X POST "https://vpn.company.com/api/groups" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "monitoring"}'
# Створюємо політику: monitoring -> prod-servers порт 9100
curl -X POST "https://vpn.company.com/api/policies" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "monitoring-to-prod",
    "enabled": true,
    "rules": [{
      "name": "prometheus-scrape",
      "enabled": true,
      "bidirectional": false,
      "protocol": "tcp",
      "ports": ["9100"],
      "sources": [{"id": "<monitoring-group-id>"}],
      "destinations": [{"id": "<prod-group-id>"}]
    }]
  }'

Важливий момент: bidirectional: false означає, що з'єднання ініціюється тільки з боку monitoring. Відповідний трафік дозволений (stateful), але prod-сервери не можуть ініціювати з'єднання до monitoring-групи за цим правилом. Це саме та поведінка, яка потрібна для zero-trust. Завдяки API-керуванню ви скорочуєте час налаштування політик на 40% порівняно з ручним редагуванням.

Як автоматизувати реєстрацію агентів через Ansible?

Агент встановлюється однією командою:

curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --management-url https://vpn.company.com --setup-key <SETUP_KEY>

Setup keys створюються в Management UI або API, можуть бути одноразовими або багаторазовими, з автоматичним призначенням у групу — зручно для автоматизації через Ansible або cloud-init:

---
# cloud-init user-data фрагмент runcmd:
- curl -fsSL https://pkgs.netbird.io/install.sh | sh
- netbird up --management-url https://vpn.company.com --setup-key {{ netbird_setup_key }}
---

DevOps-інженери можуть інтегрувати цей процес у CI/CD, використовуючи Ansible role з нашої бібліотеки. Це забезпечує одноманітне налаштування всіх вузлів.

Порівняння Netbird з Tailscale і Nebula

Netbird виграє в кастомізації політик і повному контролі над management plane, що знижує витрати на міжхмарний трафік до 30%.

Що робити, якщо P2P не встановлюється?

Статус підключень перевіряється командою:

netbird status --detail 

Вивід показує peers, їх IP в overlay, latency, relay/direct connection. Relayed з'єднання означає, що P2P не встановився — перевіряємо STUN/TURN. Якщо більшість з'єднань через relay — дивимося на NAT type на проблемних нодах. Symmetric NAT блокує прямий WireGuard handshake. Рішення: налаштувати TURN relay (coturn) і переконатися, що він доступний з обох сторін. У 80% випадків це вирішує проблему. P2P-з'єднання встановлюється за 50-100 мс при прямому з'єднанні.

Етапи впровадження Netbird

Ми ділимо роботу на етапи:

• Аналітика: оцінка поточної мережевої інфраструктури, вимог до доступу.
• Проектування: вибір груп пристроїв, політик доступу, інтеграція IdP.
• Деплой: розгортання management, signal, relay сервера у вашій інфраструктурі.
• Автоматизація: налаштування Ansible або cloud-init для автоматичної реєстрації агентів.
• Тестування: перевірка політик, продуктивності mesh, failover.
• Документація та навчання: передача runbook, інструкції для адміністраторів.

Що входить у нашу роботу

• Self-hosted Netbird stack: management, signal, relay, coturn.
• Інтеграція з Keycloak/Auth0/Azure AD.
• Бібліотека Ansible ролей для масового встановлення агентів.
• Network policies для мікросервісного доступу (HTTP, gRPC, Prometheus).
• Моніторинг (метрики Prometheus, алерти в Grafana).
• Гарантія працездатності протягом місяця після впровадження.

Вартість впровадження розраховується індивідуально залежно від складності та кількості агентів. Замовте впровадження Netbird під ключ — отримайте повну документацію та гарантію SLA. Зв'яжіться з нами для консультації.

Типові помилки та їх вирішення

1. Symmetric NAT блокує P2P: налаштування coturn relay, переконатися, що relay доступний на порту 33080.
2. Політики не застосовуються: перевірити, що групи створені та агенти зареєстровані з правильним setup key.
3. Проблеми із закінченням сертифікатів: налаштувати автоматичне оновлення через ACME (Let's Encrypt).