WireGuard, Tailscale или Headscale: что выбрать?

WireGuard против Tailscale: краткий ответ

Выбор между WireGuard и Tailscale — это не выбор между двумя протоколами, так как Tailscale и есть WireGuard. Tailscale использует то же шифрование и те же туннели, но добавляет к ним плоскость управления: координационный сервер, который обменивается публичными ключами, распределяет адреса, выполняет пробивку NAT (network address translation) и применяет политики доступа. Вы выбираете лишь то, какой объем этой координации вы готовы поддерживать самостоятельно.

Существует три честных ответа. Используйте обычный WireGuard, если у вас один сервер и несколько клиентов, которые подключаются к нему. Используйте Tailscale, если вы хотите, чтобы каждая машина могла связаться с любой другой без необходимости поддерживать файлы конфигурации. Используйте Headscale, если вам нужна такая mesh-сеть, но вы не хотите, чтобы третья сторона хранила список ваших узлов.

Что на самом деле дает control plane

Обычный WireGuard не имеет механизмов обнаружения узлов. Каждый узел — это блок текста, который вы пишете вручную: открытый ключ, строку AllowedIPs и Endpoint, если этот узел доступен. Добавление одной машины в сеть из десяти означает редактирование десяти конфигурационных файлов, так как каждая сторона должна знать ключ другой. Именно поэтому почти все self-hosted настройки WireGuard работают по схеме «звезда»: один сервер с публичным IP и клиенты, которые общаются только с ним.

Control plane избавляет от ручного редактирования. Каждый узел регистрируется один раз, получает адрес из диапазона 100.64.0.0/10 CGNAT (carrier grade NAT) и узнает открытые ключи узлов, к которым ему разрешен доступ. Туннель по-прежнему остается прямым соединением WireGuard между двумя узлами, и ваш трафик никогда не проходит через координационный сервер. Сервер передает только метаданные: кто существует, какой у них ключ и кому с кем разрешено общаться.

Это дает три конкретных преимущества.

NAT traversal. Два ноутбука за двумя домашними роутерами не имеют публичных IP-адресов. Tailscale использует STUN (session traversal utilities for NAT) для определения внешнего адреса и порта каждой стороны, после чего обе стороны одновременно отправляют пакеты. Так роутеры сначала видят исходящий поток и разрешают входящий ответ. Если это не удается, трафик перенаправляется через DERP relay — зашифрованный ретранслятор, управляемый Tailscale. Ваши данные остаются зашифрованными сквозным шифрованием (end-to-end) через ретранслятор, так как у него нет ключей. Запустите tailscale status, и в каждой строке узла будет указано direct или relay. Запустите tailscale netcheck, чтобы увидеть, какой ретранслятор ближе всего и разрешает ли ваша сеть UDP в принципе.

Ротация ключей с истечением срока действия. Ключи WireGuard не имеют срока действия. Ключ, выданный три года назад, будет работать вечно, пока вы не удалите блок узла вручную. Tailscale вместо этого ограничивает срок действия ключей узлов, и по состоянию на октябрь 2026 года стандартный срок действия в новой tailnet составляет 180 дней. Машина, которая не прошла повторную аутентификацию, перестает подключаться. Вы можете отключить истечение срока действия для каждого устройства отдельно, например, для сервера или subnet router, к которому некому будет подойти для входа в систему.

Политики вместо маршрутизации. В обычном WireGuard AllowedIPs одновременно является и таблицей маршрутизации, и списком контроля доступа, поэтому правило «alice может получить доступ к базе данных» приходится выражать через диапазон IP-адресов. Tailscale использует отдельный файл политик, где правила оперируют именами пользователей, групп и тегов. Правило может гласить, что tag:laptop может получить доступ к tag:db по порту 5432 и больше ни к чему, и это правило сохраняется даже при смене IP-адреса машины.

Цена использования control plane

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

Существует вторая цена, которую легко упустить из виду. Tailscale — это демон, работающий на каждой машине, поэтому вам придется поддерживать актуальность этого ПО на всех устройствах. Обычный WireGuard в Ubuntu 24.04 — это модуль ядра, который поставляется вместе с дистрибутивом и обновляется вместе с ядром.

Третья цена — это оплата. По состоянию на октябрь 2026 года тариф Personal бесплатен и включает неограниченное количество устройств для 6 пользователей, тариф Standard стоит 8 долларов за пользователя в месяц, а Premium — 18 долларов за пользователя в месяц. Для частного использования сервис остается бесплатным. Для команды из десяти человек — уже нет. Превышение лимита зависит в основном от количества пользователей, а не устройств, за одним исключением: серверы и другие устройства с тегами имеют собственную квоту. Каждый тариф включает 50 ресурсов с тегами, и по состоянию на октябрь 2026 года на странице цен указана стоимость 1 доллар в месяц за каждый дополнительный ресурс. Что именно покрывает бесплатный тариф стоит изучить перед тем, как приглашать седьмого пользователя или добавлять тег пятьдесят первому серверу.

Когда обычный WireGuard — верное решение

Выбирайте обычный WireGuard, если топология сети действительно представляет собой «звезду» (hub and spoke). Один VPS с публичным IP, три или четыре устройства, которые подключаются к нему, и отсутствие необходимости в том, чтобы эти устройства связывались друг с другом. Конфигурация помещается на одном экране, нет демона для обновления, нет учетной записи, которую можно потерять, и нет стороннего сервиса между вами и вашим сервером.

Это также верный выбор, если вы хотите понять уровень, на котором строится всё остальное. Самостоятельное развертывание WireGuard VPN на VPS подробно описывает генерацию ключей, wg0.conf, IP forwarding, NAT и ошибки рукопожатия (handshake). Ключи и рукопожатия по-прежнему работают в основе любой tailnet, а IP forwarding становится необходим, как только узел tailnet начинает выполнять роль subnet router или exit node. Если вы все еще рассматриваете более старый вариант, WireGuard против OpenVPN охватывает четыре случая, в которых OpenVPN сохраняет преимущество.

Установка занимает немного времени:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

Обычный WireGuard перестает быть удобным в тот момент, когда каждое устройство должно иметь доступ к любому другому устройству. Полносвязная топология (full mesh) из N узлов требует N умножить на N минус один блоков peer. При шести устройствах это тридцать блоков, которые нужно синхронизировать вручную, а дублирующая запись AllowedIPs незаметно перехватывает трафик у того узла, который был настроен первым, при этом никаких ошибок в логах не выводится.

Когда Tailscale — подходящее решение

Выбирайте Tailscale, если устройства перемещаются. Ноутбуки в отельных сетях, телефон с мобильным интернетом, домашний сервер за роутером, к которому у вас нет доступа. Это именно те случаи, с которыми обычный WireGuard справляется плохо, так как ни у одной из сторон нет стабильной публичной точки доступа, которую можно было бы указать в Endpoint.

Установка клиента выполняется одной командой из официального инсталлятора:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

tailscale up выводит URL. Откройте его, войдите в систему, и устройство будет добавлено. Не нужно копировать ключи или открывать входящие порты, так как демон устанавливает исходящее соединение с координационным сервером и поддерживает его активным. Именно поэтому узел Tailscale работает в сети, где вы вообще не контролируете файрвол.

После этого основную часть работы выполняют две настройки. Субсетевой маршрутизатор (subnet router) анонсирует целую локальную сеть в общую сеть, поэтому вам не нужно устанавливать клиент на каждое устройство:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

Маршрут остается неактивным, пока вы не одобрите его в консоли администратора, что сделано намеренно: узел не может самостоятельно внедрить маршрут в вашу сеть. Клиентам на Linux также требуется sudo tailscale set --accept-routes, так как Linux по умолчанию не принимает анонсированные маршруты. Поэтому маршрут, который выглядит одобренным на стороне сервера, не будет работать на ноутбуке с Linux, пока вы не примените эту настройку. Если вам нужен именно такой сценарий, в руководстве запуск субсетевого маршрутизатора на VPS пошагово описаны процесс одобрения и настройки пересылки трафика в порядке, который предотвращает частичную работоспособность маршрута.

Выходной узел (exit node) направляет обычный интернет-трафик клиента — то есть всё, что не предназначено для другого устройства в tailnet или одобренного субсетевого маршрута — через одну машину. Это поведение полного туннелирования, которое обычно и подразумевают под термином «VPN». На Linux для этого требуются те же настройки пересылки IP, что показаны выше, прежде чем вы сможете анонсировать узел:

sudo tailscale set --advertise-exit-node

Этот флаг — самая простая часть, а в руководстве превращение VPS в выходной узел описано, что делать дальше: одобрение маршрута в консоли администратора, а затем исправление поведения DNS и IPv6, из-за которых трафик иначе может уходить не через тот интерфейс. Если вам нужно получить доступ к одному веб-сервису, а не ко всей сети, функции serve и funnel позволяют выставить HTTPS перед конкретным локальным портом — либо только для tailnet, либо открыто для публичного интернета.

Когда Headscale — подходящее решение

Headscale — это реализация сервера координации с открытым исходным кодом, которую вы запускаете на собственном VPS. Официальные клиенты Tailscale подключаются к нему вместо облачного сервиса:

sudo tailscale up --login-server https://headscale.example.com

Путь передачи данных остаётся прежним. Это всё тот же WireGuard, работающий напрямую между узлами, если это позволяет сеть. Изменяется лишь то, что список узлов, ключи и политики хранятся в файле SQLite на вашем диске. Никто извне не может увидеть структуру вашей сети, заблокировать учётную запись или выставить счёт за количество пользователей.

Цена этого — необходимость самостоятельного обслуживания. Вы запускаете публичный HTTPS-сервис, а значит, вам потребуются доменное имя, сертификат и reverse proxy, корректно передающий WebSocket-соединения. Вы отвечаете за доступность сервера: если сервер координации недоступен, новые узлы не смогут зарегистрироваться, а существующие — узнать об изменениях. Headscale всё ещё находится в стадии разработки до версии 1.0, и в минорных релизах встречаются изменения, нарушающие обратную совместимость, поэтому перед каждым обновлением читайте changelog. В статье Запуск Headscale в качестве собственного сервера управления Tailscale описаны установка, config.yaml, ключи предварительной аутентификации и порты, которые необходимо открыть.

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

Если вы не хотите собирать этот компонент самостоятельно, самостоятельное размещение NetBird — другой способ оставить control plane внутри собственной инфраструктуры: quickstart запускает management, signal и relay-сервисы вместе на одном VPS. Однако NetBird не является полной заменой сервера Tailscale, как Headscale. Он использует собственные клиенты и собственную модель политик. Поэтому перед выбором NetBird вместо Headscale ознакомьтесь с материалом о различиях NetBird и Tailscale в правилах доступа и работе relay.

Как принять решение за один проход

Спросите, сколько машин должны взаимодействовать друг с другом. Если все они обращаются только к серверу, обычный WireGuard потребует меньше программного обеспечения для достижения того же результата.

Спросите, имеют ли машины стабильные публичные адреса. Если большинство из них находится за NAT, который вы не контролируете, вам понадобится control plane, так как пробитие NAT (hole punching) — сложная задача, которую не стоит реализовывать самостоятельно.

Спросите, кто может знать топологию вашей сети. Если ответ исключает сторонние компании или количество пользователей делает оплату за каждое рабочее место невыгодной, используйте Headscale и примите тот факт, что теперь вы обслуживаете сервер управления. Если решающим фактором является стоимость, произведите расчеты перед миграцией, так как сколько на самом деле платит команда вашего размера зависит в основном от количества учетных записей, а не от количества машин, пока число ваших помеченных серверов не превысит 50, включенных в каждый тарифный план; эти два показателя редко совпадают.

Вы можете легко изменить свое решение. Поскольку data plane во всех трех случаях использует один и тот же протокол, переход от обычного WireGuard к координированной mesh-сети требует лишь установки клиента, а не перепроектирования, а переход с Tailscale на Headscale — это перерегистрация каждого узла на другом сервере авторизации.

Чего не дают эти три решения

Ни одно из них не является межсетевым экраном. Туннель определяет, какие пакеты будут переданы, но не управляет тем, какие службы ожидают соединений. Сервер, доступный через туннель, по-прежнему доступен из интернета через любой открытый порт, поэтому продолжайте использовать правила UFW на VPS по их прямому назначению. Файл политик Tailscale ограничивает доступ других узлов, но никак не влияет на публичный интерфейс.

Ни одно из этих решений не обеспечивает аутентификацию на уровне отдельных служб и не ведет журнал действий пользователя после подключения. Рассматривайте все три инструмента как транспортный уровень, а проверки авторизации выполняйте на стороне приложения.

FAQ

Является ли Tailscale просто WireGuard с дополнительными настройками?

Tailscale использует протокол WireGuard для передачи данных, поэтому шифрование и сам туннель идентичны. Tailscale добавляет уровень координации: обмен ключами, назначение адресов, обход NAT с помощью STUN и ретрансляторов DERP, истечение срока действия ключей и файл политик, где вместо диапазонов IP-адресов используются имена пользователей. Это те компоненты, которые в обычном WireGuard вы настраиваете самостоятельно, и именно они усложняются при перемещении машин между сетями.

Проходит ли мой трафик через серверы Tailscale?

Обычно нет. Узлы соединяются напрямую друг с другом после того, как сервер координации установит между ними связь, и tailscale status показывает direct в строках этих узлов. Если прямое соединение установить не удаётся, трафик переключается на ретранслятор DERP, и в строке отображается relay. Даже в этом случае ретранслятор передаёт только зашифрованные пакеты и не имеет доступа к вашим закрытым ключам WireGuard, поэтому он не может прочитать содержимое трафика. Запустите tailscale netcheck, чтобы проверить, не блокирует ли ваша сеть UDP-трафик, необходимый для прямых соединений.

Могу ли я использовать Headscale с официальными приложениями Tailscale?

Да. Headscale использует тот же протокол управления, поэтому официальные клиенты подключаются с помощью sudo tailscale up --login-server https://headscale.example.com. Настольные и мобильные приложения также можно перенаправить на пользовательский сервер авторизации, хотя настройки на каждой платформе находятся в разных местах, а мобильные приложения чаще требуют определённой версии. Протестируйте работу на одном телефоне, прежде чем переносить всю сеть.

Нужно ли мне открывать порты для Tailscale или Headscale?

Клиенту Tailscale не нужны входящие порты, так как он инициирует исходящее соединение к серверу координации и поддерживает его открытым. Самостоятельно развёрнутому серверу Headscale требуются входящие порты: 443 для протокола управления, 80 при использовании HTTP-01 для получения сертификатов и 3478/udp только при включении встроенного ретранслятора. Обычному WireGuard необходимо открыть порт для прослушивания UDP (обычно 51820) на сервере и на любом внешнем сетевом брандмауэре вашего провайдера.

Какой из этих трёх вариантов самый быстрый?

Пропускная способность одинакова, так как все три варианта передают пакеты с помощью WireGuard. Разница проявляется в скорости установки соединения и качестве пути. Обычный WireGuard с корректным Endpoint всегда соединяется напрямую. Tailscale и Headscale в большинстве случаев соединяются напрямую, а при блокировке технологии hole punching переключаются на ретранслятор, что увеличивает задержку. Оцените свой путь с помощью tailscale ping <node>, который показывает, является ли маршрут прямым или через ретранслятор, либо с помощью iperf3 через туннель. Если полученное значение значительно ниже скорости вашего канала при прямом соединении, проблема не в выборе между этими тремя вариантами, а в несоответствии MTU пути, которое проявляется одинаково как с системой управления, так и без неё.