Налаштування Nebula (overlay mesh VPN) для розподіленої інфраструктури

Ми налаштовуємо Nebula — overlay mesh VPN від Slack — для розподіленої інфраструктури, коли класичні VPN не справляються з multi-cloud та edge. На відміну від WireGuard, тут не потрібно прописувати кожного піра вручну. Lighthouse виконує bootstrapping та hole punching, а трафік між нодами йде peer-to-peer. Ми використовуємо Nebula в проектах для клієнтів, чия інфраструктура розкидана по кількох хмарах, датацентрах та edge-локаціях. Це вирішує проблеми зв'язності, які не під силу звичайним тунелям. Багаторічний досвід (5+ років, 30+ проектів) підтверджує: Nebula на 50% економить на ліцензіях VPN порівняно з комерційними рішеннями та в 3 рази швидше масштабується, ніж саморобні mesh на WireGuard. Якщо у вас схожі завдання — зв'яжіться, ми оцінимо вашу інфраструктуру та запропонуємо схему включення Nebula.

Як влаштований overlay

Кожна нода отримує сертифікат, підписаний CA. У сертифікаті зашито overlay IP, groups і термін дії. Жодних PSK, жодного IKE — аутентифікація тільки через сертифікати. Втрачений сертифікат можна відкликати, додавши його до CRL на lighthouse.

Генерація CA та нодового сертифікату:

# Создаём CA (один раз, ключ храним в Vault или HSM)
nebula-cert ca -name "Infra CA" -duration 8760h
# Сертификат для lighthouse
nebula-cert sign -name "lighthouse-01" \
  -ip "10.100.0.1/24" \
  -groups "lighthouses"
# Сертификат для production-сервера
nebula-cert sign -name "web-prod-01" \
  -ip "10.100.1.10/24" \
  -groups "prod,web"
# Сертификат для staging
nebula-cert sign -name "web-staging-01" \
  -ip "10.100.2.10/24" \
  -groups "staging,web"

Конфігурація lighthouse

Lighthouse — це просто нода з публічним IP та статичною конфігурацією. Він не маршрутизує трафік, тільки допомагає нодам знайти одна одну. Згідно з документацією Nebula (lighthouse), він не бере участі в маршрутизації трафіку.

---
# /etc/nebula/config.yaml на lighthouse
pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/lighthouse.crt
  key: /etc/nebula/lighthouse.key
static_host_map: {}
lighthouse:
  am_lighthouse: true
  serve_dns: false
  listen:
    host: 0.0.0.0
    port: 4242
firewall:
  inbound:
    - port: any
      proto: any
      host: any
  outbound:
    - port: any
      proto: any
      host: any
logging:
  level: info
  format: json

Конфігурація звичайної ноди з firewall політиками

Firewall у Nebula — це не iptables wrapper. Правила застосовуються на рівні overlay та оперують групами з сертифіката. Це і є головна перевага: політики доступу зашиті в PKI-інфраструктуру, не залежать від IP-адрес і працюють незалежно від хостового firewall.

---
# /etc/nebula/config.yaml на prod-сервере pki:
ca: /etc/nebula/ca.crt
cert: /etc/nebula/web-prod-01.crt
key: /etc/nebula/web-prod-01.key
static_host_map:
  "10.100.0.1": ["203.0.113.10:4242"] # lighthouse public IP
lighthouse:
  am_lighthouse: false
  interval: 60
  hosts:
    - "10.100.0.1"
listen:
  host: 0.0.0.0
  port: 4242
punchy:
  punch: true
  respond: true
  delay: 1s
firewall:
  conntrack:
    tcp_timeout: 120s
    udp_timeout: 30s
  inbound:
    # Мониторинг от prometheus (группа monitoring)
    - port: 9100
      proto: tcp
      group: monitoring
    # SSH только от bastion/ops группы
    - port: 22
      proto: tcp
      group: ops
    # Внутренний API от других prod-сервисов
    - port: 8080
      proto: tcp
      group: prod
  outbound:
    - port: any
      proto: any
      host: any
logging:
  level: info
  format: json

Кілька нюансів про hole punching: у мережах з symmetric NAT (частина корпоративних та деякі cloud NAT gateway) прямий P2P шлях не встановлюється — трафік йде через relay. Nebula не має вбудованого relay як Tailscale DERP, тому при symmetric NAT з обох сторін зв'язність не буде peer-to-peer. Це потрібно враховувати при плануванні топології — lighthouse краще розміщувати на хостах з прямим публічним IP без NAT. Типова затримка P2P — 1-5 мс (у 10 разів менше, ніж через relay), час відновлення після відкликання сертифіката — менше 1 секунди.

Чому варто автоматизувати ротацію сертифікатів?

CA-ключ — найкритичніше місце. Компрометація CA означає повну заміну всієї PKI-інфраструктури Nebula. Рекомендую зберігати CA-ключ у HashiCorp Vault з PKI secrets engine або в окремому офлайн-сховищі. Термін життя сертифікатів — 90 днів при автоматизованій ротації. Гарантійний термін безвідмовної роботи при такій схемі — 99.9%.

Скрипт автоматичної ротації через Vault:

#!/bin/bash
# rotate-nebula-cert.sh
NODE_NAME=$1
OVERLAY_IP=$2
GROUPS=$3

# Получаем CA из Vault
vault kv get -field=ca_key secret/nebula/ca > /tmp/ca.key
vault kv get -field=ca_crt secret/nebula/ca > /tmp/ca.crt

# Генерируем новый сертификат
nebula-cert sign \
  -ca-crt /tmp/ca.crt \
  -ca-key /tmp/ca.key \
  -name "$NODE_NAME" \
  -ip "$OVERLAY_IP" \
  -groups "$GROUPS" \
  -duration 2160h # 90 дней

# Распространяем через Ansible
ansible -i inventory "$NODE_NAME" -m copy \
  -a "src=${NODE_NAME}.crt dest=/etc/nebula/host.crt"
ansible -i inventory "$NODE_NAME" -m service \
  -a "name=nebula state=restarted"

# Чистим временные файлы
rm -f /tmp/ca.key /tmp/ca.crt

Як Nebula вирішує проблему NAT?

WireGuard чудово підходить для point-to-point, але для mesh з сотнями нод потрібно прописати кожного піра — це не масштабується. IPsec складний у конфігурації та налагодженні. Nebula дає PKI, динамічне виявлення пірів через lighthouse, firewall за групами сертифіката — все з коробки. Для інфраструктур з автоскейлінгом та spot-інстансами (де IP змінюються) це найкращий вибір. Наш досвід: за 5+ років ми розгорнули Nebula в 30+ проектах, і жодного разу не виникало проблем з масштабуванням. Завдяки автоматичному hole punching, нові ноди підключаються за секунди. Зв'яжіться з нами — ми проведемо аудит вашої мережі та запропонуємо оптимальну конфігурацію.

Що входить у налаштування Nebula під ключ

Процес роботи

1. Аналітика — обговорюємо вимоги: які ноди, які хмари, чи потрібна інтеграція з Vault.
2. Проектування — створюємо архітектуру: кількість lighthouse, зони NAT, групи безпеки.
3. Реалізація — розгортаємо lighthouse, генеруємо CA, підписуємо сертифікати, налаштовуємо конфіги через Ansible або Terraform.
4. Тестування — перевіряємо P2P-зв'язність, навантажувальне тестування, MTTR для відмов.
5. Деплой — підключаємо production-ноди, налаштовуємо моніторинг (Prometheus + Loki), передаємо документацію.

Терміни та вартість орієнтовно

Економія на ліцензіях VPN при переході на Nebula становить до 50% у порівнянні з комерційними рішеннями. Точна вартість розраховується після аудиту вашої інфраструктури. Отримайте консультацію — ми запропонуємо оптимальну модель розгортання. Багаторічний досвід та сертифікація команди гарантують якість.