Настройка Nebula (overlay mesh VPN) для распределённой инфраструктуры

Мы настраиваем Nebula — overlay mesh VPN от Slack — для распределённой инфраструктуры, когда классические VPN не справляются с multi-cloud и edge. В отличие от WireGuard, здесь не нужно прописывать каждого пира вручную. Lighthouse выполняет bootstrapping и hole punching, а трафик между нодами идёт peer-to-peer. Мы используем Nebula в проектах для клиентов, чья инфраструктура разбросана по нескольким облакам, датацентрам и edge-локациям. Это решает проблемы связности, которые не под силу обычным туннелям. Если у вас похожие задачи — свяжитесь, мы оценим вашу инфраструктуру и предложим схему включения 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 мс, время восстановления после отзыва сертификата — менее 1 секунды.

Почему стоит автоматизировать ротацию сертификатов?

CA-ключ — самое критичное место. Компрометация CA означает полную замену всей PKI-инфраструктуры Nebula. Рекомендую хранить CA-ключ в HashiCorp Vault с PKI secrets engine или в отдельном офлайн-хранилище. Срок жизни сертификатов — 90 дней при автоматизированной ротации.

Скрипт автоматической ротации через 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% по сравнению с коммерческими решениями. Точная стоимость рассчитывается после аудита вашей инфраструктуры. Получите консультацию — мы предложим оптимальную модель развёртывания.