Что такое Tailscale и как работает эта VPN-сеть

Что такое Tailscale?

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

Это разделение составляет основу архитектуры. Плоскость данных работает по принципу peer-to-peer, а трафик между узлами зашифрован. Плоскость управления — это сервис, который Tailscale предоставляет вам. Любой важный вопрос о Tailscale, включая неудобные вопросы о доверии, вытекает из этих двух фактов. Если вы уже настраивали VPN на базе WireGuard вручную на VPS, то Tailscale — это тот же самый туннель, в котором распределение ключей и обход межсетевых экранов выполнены за вас.

Как работает Tailscale?

Ваша частная сеть узлов называется tailnet. Когда машина присоединяется к ней, происходят четыре действия.

1. Запускается демон tailscaled, который генерирует пару ключей WireGuard и сохраняет состояние в /var/lib/tailscale/tailscaled.state. Приватный ключ остается на этой машине. Формулировка Tailscale однозначна: «приватный ключ никогда, ни при каких обстоятельствах не покидает свой узел».
2. Узел авторизуется на координационном сервере и передает свой публичный ключ, а также адреса, по которым, как он считает, с ним можно связаться. Tailscale описывает этот сервер как «общий почтовый ящик для публичных ключей».
3. Координационный сервер отправляет в ответ карту сети: публичный ключ, адрес в tailnet, имя машины и возможные конечные точки каждого узла, к которому данному узлу разрешен доступ.
4. Затем каждая пара узлов пытается построить прямой туннель WireGuard между собой. Если это не удается, они передают пакеты через ретранслятор.

Каждый узел получает стабильный адрес из диапазона 100.64.0.0/10 — это диапазон carrier-grade NAT от 100.64.0.0 до 100.127.255.255. Tailscale использует этот диапазон, так как он зарезервирован для инфраструктуры провайдеров и редко конфликтует с частными адресами, которые уже используются вашими серверами. В Linux туннель отображается как интерфейс с именем tailscale0.

Реализация WireGuard работает внутри tailscaled в пространстве пользователя, а не в модуле ядра. Именно поэтому Tailscale запускается в контейнерной виртуализации, где sudo modprobe wireguard завершается с ошибкой Operation not supported. Это также означает, что предел пропускной способности на конкретном узле ниже, чем у WireGuard в ядре; это один из компромиссов, который рассматривается в сравнении Tailscale и обычного WireGuard.

Две команды показывают текущее состояние.

tailscale ip -4
tailscale status

tailscale status выводит по одной строке на каждый узел, и последний столбец является наиболее важным.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct с указанием адреса и порта означает, что две машины нашли путь друг к другу и трафик передается напрямую (peer-to-peer). relay "fra" означает, что трафик проходит через ретранслятор Tailscale во Франкфурте. - означает, что активная сессия с этим узлом в данный момент отсутствует, что является нормальным состоянием.

Что сервер координации может и чего не может видеть

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

Сервер не хранит закрытые ключи, поэтому он не может расшифровать трафик между двумя узлами. Шифрование осуществляется по принципу end-to-end между узлами WireGuard, а сервер координации не является участником этого обмена.

Что он может делать, так это передавать ключи. Любому серверу координации, будь то облачный или развернутый самостоятельно, доверяется задача сообщать вашим узлам, какие открытые ключи принадлежат данной tailnet. Это ключевой момент модели угроз, описанной ниже, и причина существования Headscale, сервера координации с открытым исходным кодом, который вы размещаете самостоятельно.

Как два сервера за разными файрволами устанавливают прямое соединение

NAT (network address translation) позволяет множеству машин использовать один публичный IP-адрес. Ваш VPS обычно имеет собственный публичный адрес, но другие машины, которые вы хотите включить в tailnet, часто его не имеют: это может быть домашний сервер, сборочный узел в офисной сети или устройство за файрволом провайдера, настройки которого нельзя изменить.

Tailscale находит путь, используя методы, основанные на стандартах STUN (session traversal utilities for NAT) и ICE. Каждый узел отправляет небольшой UDP-пакет на STUN-сервер и узнаёт публичный адрес и порт, которые его маршрутизатор назначил для этого сокета. Оба узла сообщают эти кандидаты координационному серверу, который передаёт их другой стороне. Затем оба узла начинают одновременно отправлять пакеты друг другу. Каждый маршрутизатор сначала видит исходящий пакет, поэтому он создаёт правило трансляции и принимает ответ, приходящий с того же адреса. Ни одной из сторон не потребовалось создавать входящее правило в файрволе.

Используются определённые порты. Прямые туннели WireGuard используют UDP с исходным портом, который по умолчанию равен 41641. STUN работает через UDP 3478 с ретрансляционными серверами Tailscale. Управляющее соединение и любые ретранслируемые данные используют HTTPS через TCP 443. В большинстве случаев вам не нужно открывать входящие порты, однако в сети со сложным NAT разрешение входящего UDP 41641 повышает вероятность установления прямого соединения.

tailscale netcheck

Прочтите две строки этого отчёта. UDP: true означает, что UDP вообще покидает машину, а UDP: false означает, что каждое соединение с этого узла будет ретранслироваться. MappingVariesByDestIP: true означает, что маршрутизатор назначает разный публичный порт для каждого пункта назначения, поэтому описанное выше предсказание адреса не может работать, и такие узлы обычно остаются в режиме ретрансляции.

Когда Tailscale использует ретранслятор DERP

DERP (designated encrypted relay for packets) является резервным механизмом. Tailscale поддерживает ретрансляторы во многих регионах, доступные по TCP 443. Если узел не может установить прямой путь, он отправляет свои пакеты WireGuard через один из них.

Пакеты остаются зашифрованными. Tailscale заявляет об этом прямо: «у сервера DERP нет никакой возможности расшифровать ваш трафик. Он просто слепо пересылает уже зашифрованные данные от одного узла к другому». Ретранслятор видит только зашифрованный текст и информацию о том, какой узел с каким взаимодействует.

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

tailscale ping db-1

Первые ответы приходят как via DERP(fra), затем в последующей строке отображается сообщение вида via 198.51.100.24:41641. Это изменение означает переход на прямой туннель. Если состояние не меняется, выполните tailscale netcheck на обоих концах соединения. Ретранслируемый путь продолжает работать. Это увеличивает задержку, так как каждый пакет совершает обходной путь через третью машину.

Подключение VPS к вашей tailnet

Скрипт установки поддерживает Ubuntu и Debian.

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

sudo tailscale up выводит URL. Откройте его, пройдите аутентификацию, и узел появится в вашей консоли администратора. Затем убедитесь, что демон запускается после перезагрузки, так как этот шаг часто пропускают.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled должен вывести enabled, а tailscale status должен показать новый узел с его адресом 100.x. Для сервера, развернутого с помощью скрипта, интерактивный URL не подходит. Создайте ключ аутентификации в консоли администратора и передайте его вместе с тегом, который указывает тип этой машины.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

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

Для управления парком машин важны две настройки. Срок действия ключей узлов по умолчанию составляет 180 дней (по состоянию на август 2026 года), и когда ключ истекает, «соединения с данным узлом и от него перестают работать» до тех пор, пока кто-либо не выполнит вход снова. Поэтому откройте строку машины в консоли администратора и выберите Disable Key Expiry для серверов, работающих без присмотра. MagicDNS, включенный по умолчанию для tailnet, созданных 20 октября 2022 года или позже, присваивает каждому узлу имя, например db-1.yak-bebop.ts.net, которое разрешается через stub-резолвер по адресу 100.100.100.100. Используйте имена вместо IP-адресов, так как пересозданный узел получает новый адрес, но сохраняет свое имя.

Если установка завершается ошибкой при работе с apt или репозиторием, в распространенных ошибках установки Tailscale в Ubuntu описаны способы их устранения.

Доступ к сервису, привязанному к localhost

Здесь на помощь приходит tailnet, и именно здесь пользователи часто сталкиваются с трудностями. Подключение к tailnet не делает сервис, работающий через loopback, доступным извне.

ss -tlnp | grep 3000

Если эта команда выводит 127.0.0.1:3000, значит сокет принимает только пакеты, адресованные на 127.0.0.1. Запрос от другого узла приходит на адрес 100.x этого узла, поэтому ядро не находит слушающего процесса и отвечает TCP-сбросом (reset). Клиент сообщает об ошибке Connection refused. Туннель работает исправно. Проблема заключается в настройках слушающего процесса.

Существует два корректных способа решения. Привяжите сервис к адресу tailnet вашего узла: это скроет его от публичного интерфейса без использования прокси. Передайте --bind 100.101.102.104 или эквивалентную опцию в конфигурации, а для контейнера опубликуйте порт как -p 100.101.102.104:3000:3000. Либо оставьте сервис на loopback и используйте перед ним Tailscale.

tailscale serve 3000

Это проксирует запросы на http://127.0.0.1:3000 и обслуживает их внутри вашего tailnet по имени ts.net через HTTPS, если для tailnet включены HTTPS-сертификаты. Сервис остаётся доступным только для ваших узлов. Публичная версия этой концепции называется Funnel, а в Tailscale serve и funnel описано, какой вариант выбрать.

Две связанные задачи вынесены на отдельные страницы. Для доступа ко всей частной сети, где не установлен Tailscale, требуется subnet router на VPS, а для перенаправления исходящего интернет-трафика узла через другой узел требуется exit node.

Закрытие портов, которые больше не нужны

Как только администратор получает доступ к серверу через tailnet, публичный порт 22 становится не нужен. В этом заключается практическая польза: закрытый порт невозможно подвергнуть брутфорсу, а логи перестают заполняться записями о попытках взлома.

Порядок действий имеет значение. Сначала настройте доступ через tailnet, убедитесь, что можете войти через него в рамках второй сессии, и только после этого удаляйте публичное правило.

sudo ufw allow in on tailscale0
sudo ufw status verbose

После этого удалите публичное правило SSH и переподключитесь, используя имя MagicDNS. Учтите, что именно делает ufw allow in on tailscale0: этот параметр доверяет всему трафику, поступающему через туннель, поэтому файл политик Tailscale становится основным средством контроля доступа вместо ufw. Составляйте политики с учетом этого факта.

Предупреждение для тех, кто использует контейнеры. Опубликованный порт Docker создает собственные правила NAT и обходит ufw, поэтому ufw deny не закрывает его. В Docker published ports bypassing ufw объясняется механизм этого процесса. Публикация порта на адрес tailnet, как описано выше, позволяет избежать этой проблемы.

Что защищает Tailscale, а что нет

Стоит сказать об этом прямо, поскольку маркетинговые материалы размывают границы.

Защищено: трафик между двумя узлами шифруется сквозным образом с помощью WireGuard, и ни один промежуточный ретранслятор не может его прочитать. Приватные ключи никогда не покидают машину, на которой были созданы. Узлам не требуются открытые входящие порты, поэтому в Интернете нечего сканировать на наличие портов 22 или 5432. Доступ между узлами определяется файлом политик, а не тем, кто знает адрес.

Не защищено: сервер координации видит граф ваших устройств. Эти метаданные сами по себе чувствительны, так как имена машин, владельцы, адреса и время нахождения в сети описывают вашу инфраструктуру. Он также распределяет ключи, что является более серьезным риском. Tailscale заявляет об этом прямо: «Если бы Tailscale действовал злонамеренно и скрытно добавил новые узлы в вашу сеть, то Tailscale мог бы отправлять или принимать трафик на ваши существующие узлы в открытом виде». Ваш провайдер единого входа (SSO) находится на том же пути доверия, поскольку любой, кто может создать там учетную запись, может добавить узел. А скомпрометированный узел является равноправным участником внутри tailnet, поэтому он получает доступ ко всему, что разрешают ваши политики. Является ли это приемлемым риском, зависит от того, против кого вы защищаетесь, а полная модель доверия подробно рассматривает каждый из этих случаев, включая то, что на самом деле может сделать украденная учетная запись.

Существует два ответа на риск распределения ключей. Первый — это tailnet lock, который требует, чтобы существующие доверенные узлы криптографически подписали новый узел, прежде чем остальные узлы его примут. Control plane, добавляющий узел без действительной подписи, игнорируется. Консоль администратора генерирует точную строку tailscale lock init для ваших подписывающих узлов, и каждый узел может подтвердить то, что он видит.

tailscale lock status

Все узлы должны сообщать об одном и том же наборе доверенных ключей подписи. Второй ответ — запустить control plane самостоятельно. Самостоятельно развернутый сервер координации Headscale использует тот же протокол для тех же клиентов, что переносит граф устройств и распределение ключей на оборудование, которым владеете вы. Вы также берете на себя ответственность за время безотказной работы этого сервера. Если вы все еще сравниваете self-hosted решения для control plane, а не остановились на этом, NetBird — это отдельная mesh VPN, сервер которой вы запускаете целиком на одном VPS.

Один параметр по умолчанию, который нужно исправить в первый же день. Новая tailnet поставляется с разрешительными настройками: «политика tailnet по умолчанию разрешает обмен данными между всеми устройствами внутри tailnet». Как только вы добавляете секцию acls, модель меняется на «запрещено по умолчанию», и пропускаются только ваши правила.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

Эта политика позволяет участникам tailnet подключаться по SSH к помеченным серверам и больше ни к чему. Добавляйте правила для каждого сервиса, вместо того чтобы оставлять подстановочный знак (wildcard), потому что подстановочный знак означает, что один украденный ключ от ноутбука даст доступ к вашей базе данных.

Типичные сбои и сообщения об ошибках

tailscale status всегда выдает relay. Узлы не смогли установить прямое соединение. Запустите tailscale netcheck на обоих концах. UDP: false означает, что исходящий UDP-трафик заблокирован, поэтому соединение возможно только через ретранслятор. MappingVariesByDestIP: true означает наличие жесткого NAT; часто проблему решает открытие входящего UDP-порта 41641 на стороне, которой вы управляете.

Узел, работавший месяцами, исчез. Истек срок действия ключа узла, установленный по умолчанию на 180 дней. В консоли администратора машина отображается как просроченная, а выполнение sudo tailscale up на самом устройстве восстанавливает доступ. Отключите истечение срока действия ключей на серверах, чтобы это не повторилось.

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

Имена MagicDNS не разрешаются. ping db-1 завершается ошибкой, в то время как ping 100.101.102.104 работает. Какой-то процесс заменил /etc/resolv.conf, поэтому запросы не доходят до локального резолвера по адресу 100.100.100.100. Проверьте cat /etc/resolv.conf на наличие 100.100.100.100 и выясните, какой еще софт на сервере перезаписывает этот файл. Это проблема того же класса, что и нарушение работы DNS внутри туннеля WireGuard.

tailscale up отклоняет ваш тег. Тег не объявлен в разделе tagOwners файла политик. Добавьте его туда и повторите выполнение команды.

FAQ

Является ли Tailscale VPN-сервисом или mesh-сетью?

Оба термина верны, так как они описывают разные уровни системы. Туннели строятся на базе WireGuard, что делает систему VPN. Топология является mesh-сетью, поскольку каждый узел устанавливает прямое соединение с другим узлом, с которым взаимодействует, вместо того чтобы пропускать все пакеты через центральный сервер. Сервер координации находится в плоскости управления, а не в плоскости передачи данных, поэтому при потере связи с ним существующие туннели продолжают передавать трафик. Во время сбоя становится невозможным добавление новых узлов, а также обновление ключей или политик.

Может ли Tailscale читать мой трафик?

Содержимое — нет. Трафик шифруется по принципу end-to-end между узлами с помощью WireGuard, закрытые ключи никогда не покидают узлы, а ретрансляторы DERP пересылают пакеты, которые не могут расшифровать. Tailscale видит метаданные: имена машин, владельцев, открытые ключи, адреса конечных точек и время нахождения узла в сети. Также компания занимается распределением ключей, поэтому скомпрометированный сервер координации теоретически может попытаться добавить узел, которому ваша сеть начнет доверять. Функция Tailnet lock предотвращает это, требуя подписи от ваших собственных доверенных узлов, а использование Headscale полностью исключает сторонний сервер управления из схемы.

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

Входящие — почти никогда. Согласно документации Tailscale, «в большинстве случаев открывать порты на межсетевом экране не требуется». Для исходящих соединений узлу нужен TCP 443 для связи с сервером координации и ретрансляторами, а также UDP 3478 для STUN. Прямые туннели используют UDP с портом, который по умолчанию равен 41641. Открытие входящего UDP 41641 является опциональным и помогает успешному установлению прямых соединений в сложных сетевых конфигурациях.

Почему другие узлы не могут подключиться к моему сервису на порту 3000?

Сначала проверьте адрес привязки (bind address) с помощью ss -tlnp. Слушатель на 127.0.0.1:3000 отклоняет соединения, которые приходят на 100.x адрес узла в tailnet, так как этот сокет принимает подключения только через loopback, и клиент получает Connection refused. Привяжите сервис к адресу tailnet или используйте tailscale serve 3000 для проксирования. Если слушатель уже настроен на 0.0.0.0, а соединение прерывается по таймауту вместо отказа, причина кроется в правилах политики или локальном межсетевом экране, а не в адресе привязки.

Стоит ли использовать Headscale вместо сервера координации Tailscale?

Используйте Headscale, если граф устройств или распределение ключей должны находиться на инфраструктуре под вашим контролем, или если сеть должна работать без зависимости от внешнего сервиса. Клиенты и протокол остаются прежними. Обратной стороной является то, что вы берете на себя обслуживание сервера координации, и его сбой приведет к невозможности добавления новых узлов и применения изменений в политиках. Для небольших сетей использование облачного сервера управления с включенным Tailnet lock обычно является более рациональным выбором.