Headscale vs Nebula: сравнение overlay-сетей с фокусом на производительность

Введение

Overlay-сети (mesh VPN) позволяют создавать защищённые виртуальные сети поверх существующей инфраструктуры, объединяя серверы, рабочие станции и мобильные устройства в единое пространство без привязки к конкретному провайдеру или облачной платформе. Среди open-source решений в этой категории наибольший интерес представляют Headscale (self-hosted реализация control-сервера Tailscale) и Nebula (overlay-сеть, созданная в Slack).

Оба инструмента решают одну задачу — безопасное соединение хостов через недоверенные сети — но делают это принципиально разными способами. Headscale использует протокол WireGuard, а Nebula — собственный протокол на базе Noise Framework. Это архитектурное расхождение определяет различия в производительности, удобстве развёртывания и области применения.

Данный обзор детально рассматривает архитектуру обоих решений, анализирует причины различий в производительности (с фокусом на Nebula), исследует способы оптимизации и формулирует рекомендации по выбору.

Архитектура и принципы работы

Headscale: WireGuard с управляемым control plane

Headscale — open-source реализация координационного сервера Tailscale¹. Архитектурно система состоит из двух компонентов:

• Control plane (Headscale) — сервер, отвечающий за регистрацию устройств, распределение ключей, маршрутизацию и управление ACL. Хранит состояние в SQLite или PostgreSQL.
• Data plane (Tailscale-клиент) — использует WireGuard для шифрования трафика между узлами. На Linux может работать как с ядерным модулем WireGuard, так и с userspace-реализацией wireguard-go.

NAT traversal реализован через DERP-серверы (Detoured Encrypted Routing Protocol) — TCP-relay, которые служат резервным каналом, когда прямое соединение между узлами невозможно². Tailscale поддерживает глобальную сеть DERP-серверов; при использовании Headscale можно развернуть собственные.

Аутентификация — через identity-провайдеры (OAuth2/OpenID Connect). Control plane автоматически генерирует и ротирует ключи, что минимизирует операционную нагрузку на администратора³.

Nebula: децентрализованная mesh-сеть с PKI

Nebula создана инженерами Slack для соединения десятков тысяч серверов в разных дата-центрах и облачных провайдерах⁴. Архитектура принципиально отличается от Headscale:

• Протокол — собственная реализация на базе Noise Framework (вариант NoiseIX), тогда как WireGuard использует NoiseIK⁵. Шифрование — AES-256-GCM (с поддержкой ChaCha20-Poly1305 как альтернативы).
• Lighthouse — лёгкие discovery-узлы, помогающие хостам находить друг друга. В отличие от control plane Headscale, lighthouse не управляет ключами и не принимает решения о маршрутизации — он лишь сообщает одному узлу, по какому адресу доступен другой⁶.
• Аутентификация — через сертификаты, выданные собственным Certificate Authority. Каждый сертификат содержит Nebula IP-адрес, имя хоста и список групп. Управление CA выполняется вручную — генерация, подписание и распределение сертификатов полностью лежит на администраторе⁷.
• Встроенный firewall — правила фильтрации трафика работают на каждом узле, оперируя не IP-адресами, а группами из сертификатов. Это позволяет задавать правила вида «разрешить хостам с группой WebApp доступ к порту базы данных» без привязки к конкретным адресам⁵.

Ключевая философия Nebula — децентрализация. Как отмечают разработчики:

«Мы объединили существующие концепции — шифрование, security groups, сертификаты, туннелирование — в интегрированную систему, где целое больше суммы частей»⁴.

Сравнительная таблица архитектуры

Производительность: почему Nebula медленнее

Пользователи, сравнивающие Nebula с Headscale/Tailscale, регулярно отмечают существенную разницу в пропускной способности. Причины этого различия коренятся в фундаментальных архитектурных решениях.

Главная причина: userspace vs ядро

WireGuard на Linux реализован как модуль ядра, обрабатывающий пакеты непосредственно в kernel space⁸. Это даёт критическое преимущество: пакеты не покидают ядро для шифрования/дешифрования, отсутствуют переключения контекста между kernel и userspace.

Nebula работает исключительно в userspace — каждый пакет проходит путь:

1. Приложение → ядро (сетевой стек)
2. Ядро → userspace (TUN-интерфейс → Nebula)
3. Nebula шифрует пакет
4. Userspace → ядро (UDP-сокет)
5. Ядро → сетевой адаптер

Каждый переход между kernel и userspace — это переключение контекста, копирование данных и накладные расходы на системные вызовы. Анализ через perf показывает, что основная часть CPU-времени уходит именно на операции ввода-вывода: sendmsg(), write() в TUN, read() из TUN⁹.

Tailscale тоже использует wireguard-go (userspace) на macOS и Windows, но на Linux — ядерный WireGuard¹⁰. Именно поэтому разница в производительности между Nebula и Tailscale наиболее заметна на Linux.

Количественная оценка разрыва

Официальные бенчмарки от Defined Networking (февраль 2024) на идентичном оборудовании — Dell с i7-10700, 10 Gbps NIC, MTU 1240¹¹:

На первый взгляд разница невелика при максимальной нагрузке. Однако метрика Mbps/CPU раскрывает суть: Tailscale обрабатывает вдвое больше трафика на единицу CPU, что означает — при одинаковой нагрузке Nebula потребляет существенно больше процессорного времени.

Более показательны результаты на реальном оборудовании среднего класса. На Hetzner с 1 Gbps каналом пользователи фиксировали¹²:

• Без VPN: 936 Mbps
• Через Nebula: 887 Mbps (~5% overhead)
• Через Nebula (DigitalOcean, бюджетные инстансы): 200–400 Mbps при baseline 2 Gbps

На 10 Gbps канале (Hetzner dedicated) Nebula достигала потолка в ~3.5 Gbps — при том что прямое соединение давало 9.4 Gbps¹³. Даже после устранения потерь пакетов через увеличение системных буферов, пропускная способность не росла, что указывает на bottleneck в самой обработке пакетов внутри Nebula.

Оптимизации Tailscale, недоступные Nebula

Инженеры Tailscale реализовали серию оптимизаций в wireguard-go, которые позволили userspace-реализации превзойти ядерный WireGuard на отдельных конфигурациях⁹:

1. UDP GSO (Generic Segmentation Offload) — откладывает сегментацию пакетов до последнего момента, позволяя обработать batch пакетов одним системным вызовом. Доступно с Linux 4.18.
2. UDP GRO (Generic Receive Offload) — объединяет входящие UDP-пакеты на receive path. Доступно с Linux 5.0.
3. TSO через TUN — сегменты до 64 KB проходят сетевой стек как единое целое, сокращая overhead до 44x по сравнению с обычным MTU.

Результат: wireguard-go с оптимизациями — 13 Gbps на bare metal (i5-12400), тогда как baseline wireguard-go — 8.36 Gbps⁹.

Nebula использует recvmmsg для batch-получения пакетов (параметр listen.batch, default 64)¹⁴, но не реализует GSO/GRO/TSO, что ограничивает возможности масштабирования на быстрых каналах.

Влияние MTU

Увеличение MTU TUN-интерфейса с 1500 до 9001 байт в экспериментах Tailscale дало 3-кратный прирост пропускной способности¹⁵. Это демонстрирует, что per-packet overhead в userspace-реализациях крайне высок.

Nebula по умолчанию использует MTU 1300¹⁶ — консервативное значение, безопасное для интернет-маршрутов. В контролируемой среде (AWS внутри одной AZ, где поддерживается jumbo frames) можно поднять до 8800, что существенно сокращает количество пакетов и, соответственно, overhead на каждый из них.

Проблема futex-контention

Анализ системных вызовов Nebula через strace при высокой нагрузке показал¹³:

• futex: 54.81% времени
• nanosleep: 20.97%
• recvmmsg: 9.42%

Более половины времени уходит на синхронизацию потоков (futex), что указывает на внутренние lock contention в Nebula при параллельной обработке пакетов. При этом CPU загружался неравномерно — ~125–150% spread по ядрам вместо полной утилизации одного ядра.

Платформенная специфика

На Windows производительность Nebula значительно хуже, чем на Linux — от 5 до 200 Mbps в зависимости от сценария¹⁷. Причины: менее эффективный TUN-драйвер и особенности Windows UDP-стека. В версии 1.9.x была обнаружена регрессия, приводившая к fallback на менее производительный UDP listener¹⁸.

Разработчики Nebula отмечают:

«Nebula значительно эффективнее, чем wireguard-go, на Windows и macOS»¹¹,

что, впрочем, не компенсирует разрыва с ядерным WireGuard на Linux.

Проблемы Nebula и способы их решения

NAT traversal и symmetric NAT

Наиболее частая проблема пользователей Nebula — невозможность установить прямое соединение между узлами за NAT¹⁹. Стандартный UDP hole punching работает для большинства типов NAT, но symmetric NAT (когда маршрутизатор назначает уникальный внешний порт для каждого destination) делает hole punching невозможным²⁰.

Симптоматика: узлы видят lighthouse, но не могут пинговать друг друга.

Решения:

1. Relay (с версии 1.6.0) — трафик маршрутизируется через промежуточный узел с публичным IP. Данные остаются зашифрованными end-to-end²¹. Конфигурация:

   # На relay-узле
   relay:
     am_relay: true
   
   # На клиентских узлах
   relay:
     relays:
       - 192.168.100.1
   

2. Punchy settings — для менее агрессивных NAT²²:

   punchy:
     punch: true
     respond: true
     respond_delay: 5s
   

3. Static Port на OPNsense/pfSense — эти фаерволы по умолчанию перезаписывают исходный порт UDP-пакетов, что ломает hole punching. Решение — правило «Static-Port» в Firewall → NAT → Outbound²³.

Управление сертификатами

Ручное управление PKI — главный барьер для внедрения Nebula²⁴. CA-сертификат генерируется offline, каждый хост требует индивидуального сертификата с указанием Nebula IP, имени и групп. Ротация сертификатов требует повторного распределения на все узлы.

Решения:

• Defined Networking (managed Nebula) — полная автоматизация управления сертификатами, SSO-интеграция, free tier до 100 хостов²⁵.
• Ansible/Chef/Puppet — автоматизация через Configuration Management.
• nebula-est — реализация RFC 7030 (Enrollment over Secure Transport) для автоматизации выдачи сертификатов²⁶.
• Nebula-Cert-Maker — bash-скрипты для упрощения генерации сертификатов²⁷.

Нестабильность соединений

Частые разрывы связи могут быть вызваны:

• Истечением NAT-маппинга — решается включением punchy.punch: true, что периодически отправляет keep-alive пакеты.
• Сменой IP-адреса — Nebula поддерживает roaming (смену underlay-адреса) через lighthouse notification.
• Багами в конкретных версиях — v1.9.x содержала регрессию на Windows (fallback на медленный UDP listener), ранние версии имели проблемы с recvmmsg на ядрах Linux < 2.6.34¹⁸.

Отладка

Nebula предоставляет встроенный SSH-сервер для диагностики²⁸:

sshd:
  enabled: true
  listen: 127.0.0.1:2222
  host_key: /path/to/ssh_host_ed25519_key

Доступные команды:

• list-hostmap — список известных хостов и их underlay-адресов
• query-lighthouse — запрос адреса конкретного хоста через lighthouse
• print-tunnel — информация о туннеле с конкретным пиром
• device-info — текущая конфигурация устройства

Облачные решения для Nebula

Defined Networking (managed Nebula)

Defined Networking — компания, основанная разработчиками Nebula — предлагает управляемый сервис поверх open-source Nebula²⁵:

• Автоматическое управление сертификатами — устраняет главную сложность self-hosted развёртывания
• SSO-интеграция — для организаций с несколькими администраторами
• Web UI — управление хостами, ролями, firewall-правилами через admin.defined.net
• API — автоматизация создания хостов, управления ролями, доступ к аудит-логам
• Free tier — до 100 хостов бесплатно²⁹

Процесс развёртывания:

1. Регистрация с 2FA
2. Выбор CIDR-блока для сети (необратимый выбор)
3. Развёртывание lighthouse с публичным IP
4. Enrollment хостов через generated config
5. Настройка firewall-правил

Self-hosted развёртывание

Для self-hosted Nebula минимальная инфраструктура включает:

• Lighthouse — VPS с публичным IP ($5–6/мес на Linode/DigitalOcean)³⁰. Требует минимальных ресурсов — lighthouse работает как stateless discovery-узел.
• CA — offline-хранение ключа CA (рекомендуется отдельная машина, например Raspberry Pi)²⁷.
• Config management — Ansible/Chef/Puppet для распределения сертификатов и конфигурации.

Развёртывание в облаке (AWS/GCP/Azure)

Nebula cloud-agnostic — overlay-сеть работает поверх любого провайдера:

• В AWS внутри одной AZ поддерживается MTU до 8600 (jumbo frames), между AZ — стандартный 1500¹¹.
• Terraform + Ansible — типичный паттерн для автоматизации³¹.
• Lighthouse может работать на минимальном инстансе (t3.micro / e2-micro).

Сравнение self-hosted vs managed

Оптимизация производительности Nebula

MTU

Наибольший эффект даёт увеличение MTU. Каждый пакет в userspace-реализации несёт фиксированный overhead на переключение контекста — чем меньше пакетов нужно для передачи того же объёма данных, тем меньше суммарный overhead¹⁵.

tun:
  mtu: 1300  # Default, безопасный для интернета

  # Для контролируемой среды (LAN, AWS внутри AZ):
  routes:
    - route: 10.0.0.0/16
      mtu: 8800

Nebula поддерживает per-route MTU — можно выставить высокий MTU для трафика внутри одного дата-центра и оставить 1300 для интернет-маршрутов¹⁶.

Буферы и batch-обработка

listen:
  batch: 128           # default 64, max пакетов за один syscall
  read_buffer: 10485760  # 10 MB, default: системный
  write_buffer: 10485760

Важно: параметры read_buffer/write_buffer ограничены системными настройками. Если net.core.rmem_max меньше запрошенного значения, Nebula не сможет увеличить буфер. В таком случае необходимо поднять sysctl¹³:

sysctl -w net.core.rmem_max=26214400
sysctl -w net.core.wmem_max=26214400
sysctl -w net.core.rmem_default=26214400

TX Queue

tun:
  tx_queue: 5000  # default 500

Увеличение очереди передачи помогает при burst-нагрузках, предотвращая drop пакетов на TUN-интерфейсе¹⁶.

NAT traversal

Для максимально быстрого установления прямых соединений:

punchy:
  punch: true
  respond: true
  delay: 1s
  respond_delay: 5s

Прямое соединение (peer-to-peer) всегда быстрее relay — relay добавляет дополнительный hop и увеличивает latency²¹.

Выбор шифра

Nebula поддерживает AES-256-GCM (default) и ChaCha20-Poly1305. На процессорах Intel/AMD с аппаратным ускорением AES (AES-NI) — AES-256-GCM быстрее. На ARM или старых CPU без AES-NI — ChaCha20-Poly1305 может быть предпочтительнее¹². Важно: все узлы сети должны использовать один и тот же шифр.

Сводка оптимизаций по приоритету

Плюсы и минусы

Headscale

Преимущества:

• Использует WireGuard — зрелый, аудированный протокол с ядерной реализацией на Linux
• Совместимость с официальными клиентами Tailscale на всех платформах
• Автоматическое управление ключами и ротация сертификатов
• SSO через OAuth2/OpenID Connect
• Низкий порог входа — «установи и войди»³
• DERP-relay обеспечивает связность даже через самые агрессивные NAT (TCP fallback)

Недостатки:

• Зависимость от control plane — при его недоступности новые соединения невозможны
• Реализует проприетарный протокол Tailscale (open-source клиент, но не протокол)
• Меньше контроля над сетевой политикой по сравнению с Nebula
• Headscale — сторонний проект, не от Tailscale; совместимость может ломаться при обновлениях Tailscale

Nebula

Преимущества:

• Полная независимость от вендора — MIT-лицензия, нет привязки к проприетарному протоколу
• Децентрализация — lighthouse нужен только для discovery, не для работы⁶
• Встроенный firewall с group-based правилами⁵
• Проверено на масштабе 50K+ хостов в production (Slack)⁴
• Минимальное потребление памяти (27 MB vs 200+ MB у Tailscale)¹¹
• Cloud-agnostic — работает идентично на любой инфраструктуре

Недостатки:

• Только userspace — ядерная реализация недоступна, что ограничивает throughput на быстрых каналах
• Ручное управление PKI без дополнительных инструментов²⁴
• Высокий CPU overhead на пакет (Mbps/CPU: 1500 vs 3200 у Tailscale)¹¹
• Проблемы с symmetric NAT без relay-узлов²⁰
• Ограниченная производительность на Windows¹⁷
• Нет встроенного web UI для управления
• Отсутствие SSO в open-source версии

Дискуссионные вопросы и противоречия

«Nebula медленная» — миф или реальность?

Официальные бенчмарки Defined Networking показывают, что Nebula способна насыщать 9 Gbps канал¹¹. Однако пользовательские тесты на 10 Gbps каналах фиксируют потолок в 3.5 Gbps¹³. Разработчики объясняют это различием в оборудовании и конфигурации, но сам факт bottleneck в обработке пакетов подтверждается анализом через strace (futex contention).

Разработчики сами озаглавили свой benchmark-пост «Nebula is not the fastest mesh VPN»¹¹, открыто признавая, что приоритет — предсказуемость и экономия ресурсов, а не максимальная пропускная способность.

Userspace — неустранимое ограничение?

Tailscale продемонстрировала, что userspace-реализация (wireguard-go) может превзойти ядерный WireGuard при использовании GSO/GRO/TSO оптимизаций⁹. Теоретически аналогичные оптимизации могут быть применены в Nebula. На практике это требует значительной переработки сетевого стека Nebula, и на момент исследования подобные изменения не анонсированы.

Сертификаты vs SSO

Сертификатная модель Nebula даёт криптографически строгую идентификацию без зависимости от внешних сервисов — но ценой ручного управления. Tailscale/Headscale делегирует идентификацию identity-провайдерам, что удобнее, но создаёт зависимость от доступности SSO-сервиса. Managed Nebula от Defined Networking предлагает компромисс — SSO поверх сертификатной модели.

Рекомендации по выбору

Выбирайте Headscale, если

• Нужна максимальная производительность на Linux (ядерный WireGuard)
• Важна простота развёртывания и управления
• Требуется SSO-интеграция
• Команда небольшая, инфраструктура умеренного масштаба
• Приемлема зависимость от Tailscale-экосистемы

Выбирайте Nebula, если

• Критична полная vendor-независимость
• Нужен распределённый firewall с group-based правилами
• Масштаб — тысячи и десятки тысяч хостов
• Предсказуемость потребления ресурсов важнее пиковой скорости
• Команда готова управлять PKI (или использовать Defined Networking)
• Lighthouse-архитектура предпочтительнее центрального control plane

Выбирайте Managed Nebula (Defined Networking), если

• Нравится архитектура Nebula, но не хочется управлять PKI
• Нужна автоматизация сертификатов и SSO
• Сеть до 100 хостов (free tier)

Если Nebula медленная — чеклист оптимизации

1. Убедиться, что соединение прямое (не через relay) — nebula-ssh list-hostmap
2. Поднять MTU до максимума среды (8800 в LAN/облаке)
3. Увеличить системные буферы (net.core.rmem_max, wmem_max)
4. Настроить listen.batch: 128, tun.tx_queue: 5000
5. Включить punchy.punch: true и punchy.respond: true
6. Проверить наличие AES-NI на CPU (grep aes /proc/cpuinfo)
7. На Windows — обновиться до последней версии (значительные улучшения производительности в свежих релизах)

Quality Metrics