Netbird или Tailscale: self-hosted альтернативы — сравнение

MAATRIX

Если вы уже решили, что хотите mesh-VPN на WireGuard с автоматической раздачей ключей и ACL между устройствами, но не хотите зависеть от чужого облака — выбор обычно сужается до двух вариантов: Netbird в self-hosted режиме или Tailscale через открытую реализацию control-сервера Headscale. Оба решают одну задачу разными архитектурными путями, и разница между ними — не в маркетинге, а в том, сколько сервисов вам придётся администрировать и насколько «полная» получится копия исходного продукта.

Что вообще значит «self-hosted» в обоих случаях

Важно сразу развести два понятия: control-plane (координационный слой — кто в сети, какие у кого ключи, кому что можно) и data-plane (собственно передача трафика между устройствами). В обеих системах сам трафик — это WireGuard, который по возможности идёт напрямую между узлами (peer-to-peer через NAT traversal), а если не пробивается — через relay-сервер, который видит только зашифрованные пакеты.

Разница — в том, что такое «control-plane» технически:

• Tailscale + Headscale: Headscale — это open-source реинжиниринг протокола, которым официальный клиент tailscale разговаривает с login.tailscale.com. Вы ставите один Go-бинарник, направляете туда официальный клиент флагом --login-server, и он не отличает Headscale от настоящего облака. Но Headscale поддерживается сообществом, а не Tailscale Inc., и не является «Tailscale minus облако» на 100% — это независимая реализация протокола, местами отстающая от новых фич SaaS-версии.
• Netbird self-hosted: это тот же код, что и в облаке Netbird, просто развёрнутый у вас — никакого реверс-инжиниринга протокола нет, потому что вендор сам публикует self-hosted дистрибутив. Из коробки это уже не один бинарник, а набор сервисов: management, signal, relay/coturn, dashboard и отдельный identity provider (по умолчанию Zitadel). Подробный процесс разобран в статье про self-hosted Netbird на Ubuntu 24.04 и на Debian 12.

Отсюда первое практическое следствие: Headscale — это одна точка отказа и один сервис для бэкапа и мониторинга; Netbird self-hosted — это малый дистрибутивный стек из 5-6 контейнеров, каждый из которых можно уронить по отдельности.

Архитектура и компоненты: один бинарник против стека контейнеров

Ключевое отличие с точки зрения эксплуатации: Headscale можно поднять на 1 vCPU / 1 ГБ RAM буквально за полчаса — там нет отдельного identity-сервиса, регистрация узлов идёт через простые preauth-ключи (headscale preauthkeys create --user ivan --expiration 24h --reusable). Netbird же тянет за собой полноценный identity provider, а значит и его собственную базу, TLS-сертификат под отдельный поддомен и потенциально OIDC-интеграцию с внешним провайдером, если Zitadel не устраивает.

Практически это означает: если у вас уже есть корпоративный SSO (Keycloak, Okta, Google Workspace) и вы хотите заводить пользователей через него с ролями и группами — Netbird ближе к «enterprise»-модели из коробки. Если нужен быстрый приватный mesh на десяток серверов без отдельной системы авторизации — Headscale поднимается заметно быстрее.

Ресурсы сервера и требования к инфраструктуре

Разница в требованиях к железу прямо вытекает из архитектуры:

Headscale:      1 vCPU / 1 GB RAM — комфортно для сотен узлов
Netbird stack:  2 vCPU / 2-4 GB RAM — management + signal + relay + Zitadel + Postgres

Это не значит, что Netbird «тяжёлый» — просто он несёт больше сервисов одновременно. На практике для команды до 20-30 устройств хватит скромной VPS в обоих случаях, но при росте сети Netbird быстрее упрётся в память из-за Zitadel и Postgres, если не разнести компоненты по разным машинам.

Обоим решениям нужен домен с A-записью на IP сервера и открытый порт 443/tcp под reverse-proxy (Caddy или nginx с TLS) — без валидного сертификата официальные клиенты tailscale и netbird не подключатся к control-серверу. Netbird дополнительно просит открыть UDP-порты для coturn (обычно 3478 и диапазон relay-портов), Headscale по умолчанию обходится публичной DERP-инфраструктурой Tailscale и может вовсе не открывать ничего, кроме 443.

ACL и управление доступом между устройствами

Обе системы дают сегментацию «кто с кем может соединяться», но выражают её по-разному.

В Headscale политика — файл YAML/HuJSON с группами, тегами и явными правилами accept:

groups:
  group:admins:
    - ivan

tagOwners:
  tag:servers:
    - group:admins

acls:
  - action: accept
    src:
      - group:admins
    dst:
      - tag:servers:22,443

В Netbird та же логика настраивается через веб-панель Dashboard (или API) — группы устройств, Policies (правила доступа между группами), Nameservers для DNS. Разница не столько в возможностях (обе модели умеют группы, теги/лейблы и точечные правила по портам), сколько в интерфейсе: Headscale — это текстовый файл, который удобно версионировать в git и катить через CI, Netbird — веб-UI, который проще освоить нетехническому админу, но менее удобен для GitOps-подхода без обращения к API отдельно.

Если в команде уже есть практика хранить инфраструктурные политики как код — Headscale ближе к этому подходу. Если нужен визуальный интерфейс для не-инженеров, которые сами добавляют правила — Netbird выигрывает за счёт готового Dashboard.

NAT traversal, relay и что происходит, если сервер упал

В обоих случаях control-plane не находится в пути трафика — WireGuard-туннели между уже подключёнными устройствами продолжают работать, даже если Headscale или management-сервер Netbird временно недоступны. Пострадает только:

• регистрация новых устройств;
• обновление ACL/политик и карты сети;
• пересборка туннеля, если один из узлов сменил IP и нужна новая координация (roaming).

Разница в relay-инфраструктуре: Headscale по умолчанию использует публичную DERP-карту Tailscale — то есть даже self-hosted control-plane частично полагается на инфраструктуру вендора для проброса NAT, если пиры не могут связаться напрямую. Это не проблема приватности (DERP видит только зашифрованные WireGuard-пакеты), но противоречит идее «всё под своим контролем» в чистом виде — если это принципиально, DERP-релей можно поднять свой отдельно.

Netbird self-hosted включает coturn в комплект поставки сразу — relay-инфраструктура с первого дня работает на вашем сервере, без зависимости от чужих STUN/TURN. Для сценариев с юридическими требованиями к локализации трафика (не только метаданных, но и потенциального relay-пути) это более чистое решение из коробки.

Миграция и путь наименьшего сопротивления

Если у вас уже есть парк устройств с официальным клиентом tailscale, миграция на свой Headscale не требует переустановки пакета — достаточно перелогиниться на новый control-сервер:

tailscale down
tailscale up --login-server https://hs.example.com --force-reauth --authkey <preauth-key>

С Netbird ситуация аналогичная — клиент netbird тоже принимает URL своего management-сервера при первом запуске (netbird up --management-url https://nb.example.com), но если вы стартуете с нуля, а не мигрируете с облака, разница в том, что Netbird сразу даёт готовый Dashboard и, за счёт встроенного coturn, не тянет внешние зависимости для NAT traversal.

Если вы уже сравнивали ручную настройку WireGuard-туннелей без control-plane вообще, стоит взглянуть на статью про WireGuard на Ubuntu 24.04 — она показывает, сколько ручной работы (обмен ключами, конфиги на каждом пире) автоматизируют и Netbird, и Headscale. Кроме них на рынке есть ещё Netmaker и ZeroTier с собственным контроллером ztncui — тоже self-hosted mesh-решения поверх WireGuard/собственного протокола, если хочется сравнить больше вариантов перед выбором.

Частые вопросы