Безопасен ли Tailscale: модель доверия

Безопасен ли Tailscale? Краткий ответ

Безопасен ли Tailscale? Если говорить о том, что беспокоит большинство пользователей, то да: coordination server, который обслуживает ваш tailnet, никогда не хранит private keys, используемые для шифрования трафика, поэтому не может прочитать данные, которыми ваши устройства обмениваются друг с другом. На странице безопасности Tailscale это сформулировано прямо: «Private keys никогда не покидают устройство. Весь трафик всегда шифруется сквозным шифрованием». Однако полезно задать другой вопрос. Если coordination server будет взломан или получит обязательное по закону требование, ему не нужно читать ваши пакеты. Он определяет, каким public keys доверяют ваши устройства, поэтому может подключить устройство, которое вы не разрешали подключать.

Одним предложением модель доверия можно описать так: шифрование защищает данные, а control plane определяет состав участников. В каждом разделе ниже указано, кому вы должны доверять, что именно эта сторона может сделать и какой контроль ограничивает её возможности. Если продукт вам пока незнаком, начните с материала что такое Tailscale и как работает его mesh.

Плоскость управления и плоскость данных разделены

Tailscale — это mesh VPN (виртуальная частная сеть) на базе WireGuard, того же протокола, который вы могли бы настроить вручную на собственном WireGuard VPS. Каждое устройство локально создаёт собственную пару ключей WireGuard. В статье Tailscale как это работает сервер координации назван «общим ящиком для открытых ключей». В ней также сказано: «Закрытый ключ никогда, ни при каких обстоятельствах не покидает свой узел».

Плоскость данных — это зашифрованный трафик между вашими устройствами. Он передаётся напрямую от устройства к устройству, если сеть это позволяет. Плоскость управления — это всё остальное: какие устройства входят в tailnet, какой открытый ключ относится к каждому устройству, политика доступа, настройки DNS и список relay-серверов. Tailscale предоставляет плоскость управления как хостируемый сервис. Плоскость данных работает на ваших собственных машинах.

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

Что может сделать скомпрометированный coordination server?

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

Он может добавить node. Когда Tailscale объявила tailnet lock, компания описала риск своими словами: вредоносный сервер может «использовать тайно добавленный node для отправки или получения трафика от уже существующих node», и тогда «не имеет значения, что трафик зашифрован, поскольку сам peer может быть вредоносным». Устройство доверяет peer, потому что control plane сообщает ему, что этот ключ принадлежит tailnet.

Он может изменить список устройств, к которым разрешён доступ. Политика доступа хранится в control plane и распространяется на node. В white paper Tailscale о tailnet lock сказано, что tailnet lock «не предотвращает нарушение connectivity в вашей сети скомпрометированным control plane, например из-за отказа распространять ключи новых node или распространения политики контроля доступа, запрещающей доступ ко всем node».

В любом случае он видит метаданные соединений. Network flow logs Tailscale записывают события открытия и закрытия каждого соединения между машинами. В документации указано, что эти журналы «строго не содержат сведений о действиях клиентов или содержимом network traffic». Поэтому control plane может знать, какие ваши устройства взаимодействовали друг с другом и когда. Он не знает, что именно они передавали.

Только один пункт из этого списка относится к шифрованию. Остальные связаны с тем, кто входит в tailnet, и с содержанием политики. Поэтому особое внимание следует уделить controls, которые управляют добавлением node.

Поставщик удостоверений — корень доверия для tailnet

Tailscale не хранит собственную базу паролей. В документации прямо указано, что паролей Tailscale не существует, а вход делегирован поставщику удостоверений (IdP): Apple, Google, GitHub, Microsoft, Okta, OneLogin или пользовательскому поставщику OpenID Connect.

Рассматривайте это как утверждение о безопасности, потому что так и есть. Любой, кто может войти в вашу учётную запись Google или Microsoft, может войти в ваш tailnet. Многофакторную аутентификацию (MFA) определяет IdP. Процесс отзыва доступа при увольнении пользователя определяется действиями IdP. Скомпрометированная учётная запись IdP становится учётной записью tailnet, и злоумышленнику не нужно атаковать WireGuard: он добавляет устройство и получает все права, предоставленные этому пользователю вашей политикой.

Между украденной учётной записью и работающим устройством внутри вашего tailnet находятся два механизма контроля: подтверждение устройств и истечение срока действия ключей. Tailnet lock — третий механизм. Он предназначен для защиты плоскости управления, а не учётной записи.

Одобрение устройств: подключение происходит только после подтверждения

В документации Tailscale одобрение устройств описано как функция, которая «позволяет администраторам сети Tailscale проверять и одобрять новые устройства до их подключения к сети Tailscale». Одобрить устройство может Owner, Admin или IT admin. Пока никто не примет решение, на странице Machines рядом с новым устройством отображается метка «Needs approval».

Включите эту функцию, и сценарий с украденной учётной записью изменится. Злоумышленник войдёт в систему, устройство зарегистрируется, но не сможет получить доступ к ресурсам. Оно будет ожидать одобрения, а в административной консоли рядом с ним будет отображаться метка, указывающая, что неизвестная вам машина пытается подключиться. Автоматизация при этом продолжит работать: при создании auth key можно отметить его как предварительно одобренный, а устройства можно одобрять через API.

Auth keys — ещё один способ получить доступ, поэтому обращайтесь с ними как с учётными данными. В документации Tailscale прямо указано, чем опасны ключи определённого типа: «Будьте очень осторожны с многоразовыми ключами! При краже они могут представлять серьёзную опасность. Лучше всего хранить их в хранилище ключей, специально предназначенном для этой цели». По состоянию на August 2026 документированный срок действия ключа составляет от 1 до 90 дней. Если срок не указан, по умолчанию используется максимальное значение — 90 дней. Предпочитайте одноразовые ключи. Для временных машин, которые регулярно создаются и удаляются, помечайте ключи как ephemeral. Многоразовые ключи храните в зашифрованном виде с помощью Ansible Vault или в secrets manager, а не в shell script.

Срок действия ключей: таймер, который ограничивает последствия всех остальных ошибок

Срок действия ключей узлов истекает. Благодаря этому украденное или забытое устройство становится временной проблемой. В документации Tailscale указано: «По умолчанию для новых доменов устанавливается срок действия 180 дней». Также в ней сказано: «Если повторная аутентификация не выполняется, срок действия ключей истекает, и подключения к указанной конечной точке и от неё прекращают работать». Вы можете самостоятельно повторно аутентифицировать устройство:

tailscale up --force-reauth

В документации есть предупреждение: это действие «может прервать подключение tailnet, поэтому его не следует выполнять удалённо через SSH или RDP, если у вас нет другого способа войти в систему при потере подключения». Выполняйте команду при открытом доступе к консоли или через второй канал подключения к машине. Иначе вы можете прервать работу сети, которую используете для доступа.

На серверах этим механизмом часто пренебрегают. Машина, которой требуется повторная аутентификация каждые 180 дней, отключится от tailnet в 3:00, когда никто не контролирует её работу. Поэтому администраторы отключают для неё срок действия ключа. Это удаляет таймер, который в конечном итоге прекратил бы действие украденного ключа. Для сервера лучше использовать устройство с тегом. Тег назначается машине, а не пользователю, поэтому машина продолжит работать после ухода сотрудника из компании. В любом случае ведите список машин, для которых отключён срок действия ключей. Такие ключи остаются действительными, пока вы не удалите устройство.

Tailnet lock: вывод coordination server из цепочки доверия

Tailnet lock напрямую решает проблему регистрации устройств. В документации Tailscale по tailnet lock описан этот механизм: «Когда новый узел присоединяется к tailnet, его открытый ключ узла должен иметь подпись ключа Tailnet Lock. Coordination server передаёт подписанный открытый ключ узла узлам-пира́м». Существующие устройства проверяют эту подпись до того, как принять пир. Поэтому ключ узла, который control plane создал самостоятельно, отклоняется.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init включает эту функцию. На этом этапе вы указываете узлы, которые будут подписывать ключи. Tailscale требует как минимум два узла-подписанта при инициализации и допускает не более 20 таких узлов в tailnet. После этого для каждого нового устройства требуется подпись одного из них. Это создаёт реальные операционные затраты: чтобы добавить телефон, нужно выполнить команду на ноутбуке.

Ограничения описаны в документации. Они важнее описания самой функции:

• Если вы потеряете секрет отключения, восстановление невозможно. В документации сказано: «Если вы потеряете секреты отключения и не передадите ни один из них в службу поддержки Tailscale, tailnet невозможно восстановить».
• Ключ подписи хранится на принадлежащем вам устройстве, поэтому защищённость ключа зависит от безопасности этого устройства. В документации прямо сказано: «Если устройство скомпрометировано, ключ можно получить».
• Одновременно использовать оба механизма нельзя. Tailscale указывает, что tailnet lock и одобрение устройств взаимоисключают друг друга. Включение одного механизма означает отказ от другого.
• Это модель доверия при первом использовании (TOFU). Первоначальная настройка всё ещё проходит через control plane. Точка доверия перемещается в вашу собственную сеть только после этого первого шага.

Tailnet lock защищает членство в сети. Доступность он не защищает, и в white paper это прямо указано.

Раскрывает ли моём трафике соединение через relay?

Нет. Если два устройства не могут связаться напрямую, трафик проходит через DERP-сервер (Designated Encrypted Relay for Packets). В документации Tailscale это указано однозначно: «Поскольку закрытые ключи Tailscale никогда не покидают локальное устройство, на котором они были созданы, DERP-сервер не может расшифровать ваш трафик. DERP-сервер без анализа пересылает уже зашифрованный трафик от одного устройства к другому».

Relay снижает скорость соединения и видит метаданные: две зашифрованные конечные точки, а также время и объём передаваемых данных. Чтобы определить фактический тип соединения, выполните:

tailscale status
tailscale netcheck

tailscale status помечает каждый peer как direct, который выводится как direct 203.0.113.10:41641, или relayed, который выводится как relay с именем relay после него. После имени указаны счётчики байтов. Если peer постоянно использует relay, это означает, что конечные точки не смогли создать прямой маршрут. Обычно причина в блокировке UDP или в том, что обе стороны находятся за строгим NAT (network address translation). tailscale netcheck показывает, работает ли UDP на этом компьютере, как NAT сопоставляет порты и какова задержка до ближайших relay. По этим данным можно определить, какая из двух причин действует.

Выходной узел меняет точку выхода в Интернет, но не устраняет её

Выходной узел направляет весь публичный интернет-трафик устройства через другое устройство в tailnet, используя маршруты по умолчанию 0.0.0.0/0 и ::/0. В Linux компьютер, предоставляющий эту возможность, объявляет себя выходным узлом, а каждый клиент подключается к нему отдельно:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Выходной узел должен быть одобрен пользователем с ролью Owner, Admin или Network admin в консоли администрирования. Кроме того, политика доступа должна разрешать autogroup:internet, прежде чем клиент сможет его использовать. Оба шага выполняются явно: неодобренный компьютер не может незаметно стать точкой выхода для всего tailnet.

Теперь о доверии. Трафик от ноутбука до выходного узла передаётся в зашифрованном виде. Затем он выходит из этого компьютера как обычный интернет-трафик и содержит IP-адрес этого компьютера. Поэтому оператор выходного узла видит адреса назначений. Их также видят хостинг-провайдер компьютера и его вышестоящая сеть. Вы переместили точку наблюдения, а не устранили её. Это разумный компромисс, если вы контролируете удалённую сторону. Именно поэтому имеет смысл запустить собственный выходной узел на VPS. Если вы не контролируете её, такой вариант менее надёжен.

Политика по умолчанию создаёт плоскую сеть

Новый tailnet работает с разрешительной политикой. В документации Tailscale по управлению доступом сказано, что файл политики по умолчанию «разрешает обмен данными между всеми устройствами внутри tailnet». Каждое устройство может подключиться к любому другому устройству через любой порт. Это плоская сеть. Вы перенесли её внутрь туннеля. Это защищает от внешних источников и не помогает против заражённого ноутбука.

Ужесточите политику в файле политики tailnet. Он поддерживает списки управления доступом (ACL) и новый формат grants. Оба варианта записываются на диалекте JSON, который допускает комментарии:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

Эта политика разрешает одной группе подключаться по SSH к production-серверам, позволяет участникам использовать exit node и запрещает всё остальное, поскольку для этого нет правил. Tailscale указывает, какие цели правил доступны на каждом плане. Проверьте это до того, как будете использовать tags или autogroups, и ознакомьтесь с содержимым бесплатного плана. Для устройства, которое вообще не должно принимать входящие подключения, например личного телефона, tailscale set --shields-up блокирует их на стороне клиента.

Что меняется при самостоятельном размещении control plane с Headscale

Headscale — это «реализация сервера управления Tailscale с открытым исходным кодом для самостоятельного размещения». В README честно определены границы проекта: «Он реализует ограниченный набор функций для одной сети Tailscale (tailnet), подходящей для личного использования или небольшой организации с открытым исходным кодом». В список функций входят ACL и grants, subnet routers, exit nodes, встроенный DERP server, Tailscale SSH и Taildrop. Если именно ограниченный набор функций создаёт проблему, NetBird — другая mesh-система с control plane, который можно разместить самостоятельно. Размещение NetBird server на собственном VPS позволяет принять такое же решение о регистрации устройств на оборудовании, которым вы владеете.

Меняется сторона, которая может зарегистрировать rogue node. В Headscale каталог ключей и политика находятся на вашем сервере. Ни одна третья сторона не хранит список публичных ключей ваших устройств. Ни одну третью сторону нельзя обязать передать такой ключ или подписать его.

Data plane не меняется. Используется тот же WireGuard с тем же сквозным шифрованием и тот же relay fallback, когда прямой путь недоступен. При этом вы берёте на себя задачи, которые выполнял Tailscale: обеспечение доступности, установку обновлений, резервное копирование и физическую защиту сервера. Взломанный Headscale host даёт атакующему ровно те возможности, которые дал бы взломанный coordination server: регистрировать узел и распространять policy. Tailnet lock не входит в список функций Headscale, поэтому соответствующий компенсирующий контроль здесь недоступен. Если решающим для вас является вопрос владения, в материале Самостоятельное размещение control plane с Headscale описана настройка.

От чего защищает Tailscale

• Открытые порты, доступные из Интернета. Сервис, привязанный к адресу tailnet, недоступен из Интернета, поэтому сканеры, которые проверяют каждый VPS на порту 22, его не видят. Исключение создаёте вы сами: Funnel намеренно публикует сервис tailnet в открытом Интернете. Поэтому перед выполнением любой из этих команд стоит знать где заканчивается serve и начинается funnel. При этом не отключайте межсетевой экран хоста: опубликованный порт Docker добавляет собственные правила и обходит ufw на публичном интерфейсе.
• Подбор паролей для доступных извне учётных записей. Если порт отвечает только внутри туннеля, перебирать пароли не для чего. Это надёжнее, чем ограничивать частоту запросов на открытом порту. Но fail2ban в Ubuntu 24.04 всё равно стоит использовать для сервисов, которые должны оставаться общедоступными.
• Недоверенные сети на маршруте. Трафик между вашими компьютерами шифруется от конца до конца при передаче через сеть кафе или общую локальную сеть провайдера. При ретрансляции он также остаётся зашифрованным.
• Ручное распространение ключей. Каждый узел, добавленный вручную в конфигурацию WireGuard, создаёт риск повторно использовать адрес или вставить неправильный ключ. Mesh-сеть ведёт эти данные за вас. В этом заключается основная практическая разница между WireGuard и Tailscale.

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

• Скомпрометированное конечное устройство. tailnet доверяет устройствам. Вредоносное ПО на одобренном ноутбуке получает доступ к туннелю, адресам tailnet и ко всему, что разрешено этому пользователю политикой. Это основной пробел в защите, и ни один VPN его не устраняет.
• Злонамеренный или неосторожный администратор. Любой, кто может изменять файл политики, может предоставить себе доступ к любым ресурсам. То же может сделать тот, кто захватил учётную запись владельца. Проверяйте изменения политики так же, как проверяете код.
• Анализ трафика. Ваш интернет-провайдер видит зашифрованный UDP-трафик к конечному устройству, а также время и объём передачи данных. В журналах потоков Tailscale видно, какие узлы взаимодействовали и когда. Содержимое не видно ни одной из сторон, но сам факт соединения не скрыт. Перед выбором инструмента для этой задачи ознакомьтесь с материалом о различиях между Tor и VPN.
• Уже утраченное устройство. Истечение ключа — медленная резервная мера с периодом по умолчанию 180 дней. Быстрой мерой служит удаление устройства в консоли администрирования. Заранее выясните, где находится эта кнопка.

Проверьте собственный tailnet

1. Выполните tailscale status на устройстве и просмотрите список узлов. Устройство, которое вы не можете идентифицировать, — именно та ситуация, для предотвращения которой существует одобрение устройств.
2. Выполните tailscale lock status, чтобы проверить, включён ли tailnet lock, затем решите, оправдывает ли стоимость подписания каждого нового устройства использование этой функции в вашем tailnet.
3. Откройте консоль администрирования и отметьте все машины с отключённым сроком действия ключа, а также все многоразовые ключи аутентификации, которые ещё существуют. В обоих случаях это учётные данные без ограничения по времени.
4. Прочитайте файл политики. Если в нём по-прежнему используются настройки по умолчанию, каждое устройство может обращаться к любому другому устройству по любому порту, и один заражённый ноутбук получает доступ ко всем ним.

Tailscale заслужил репутацию благодаря плоскости передачи данных: архитектура не позволяет оператору читать ваш трафик. Принимайте это утверждение в том виде, в котором его формулирует поставщик, а затем проверьте принадлежащие вам компоненты: учётные записи, настройку одобрения, список сроков действия и файл политики. На странице безопасности Tailscale указана сертификация SOC 2 Type II и продолжающаяся работа в сфере безопасности с Latacora. Это свидетельствует об их процессах, но не описывает конфигурацию вашей системы.

FAQ

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

Нет. Трафик шифруется с помощью ключей WireGuard, которые создаются на ваших устройствах. На странице безопасности Tailscale указано: «Приватные ключи никогда не покидают устройство. Весь трафик всегда шифруется сквозным шифрованием». Это относится и к соединениям, которые используют резервный ретранслятор DERP, поскольку ретранслятор «вслепую пересылает уже зашифрованный трафик от одного устройства к другому» и не располагает ключом для расшифровки. Инфраструктура Tailscale видит только метаданные: какие устройства существуют, какие из них соединялись друг с другом и когда это происходило.

Что фактически может сделать скомпрометированный сервер координации Tailscale?

Он может зарегистрировать узел. В собственном объявлении tailnet lock компания Tailscale описывает риск скрытно добавленного узла, который может «отправлять трафик существующим узлам и принимать от них трафик». Шифрование в этом случае не помогает, «поскольку сам узел может быть вредоносным». Скомпрометированный control plane также может распространить политику, изменяющую доступ устройств, а в документе tailnet lock отмечается, что он может нарушить соединение, не распространив новые ключи узлов. Однако расшифровать трафик между существующими устройствами он не может, поскольку никогда не хранил их приватные ключи.

Скрывает ли exit node мои действия в Интернете от моего ISP?

Он скрывает назначения от сети, к которой вы подключены, включая ISP домашней сети или кафе, поскольку всё покидает устройство в виде зашифрованного трафика, адресованного exit node. Это не делает вас анонимным. Теперь эти назначения видит exit node. Их также видят его hosting provider и вышестоящая сеть, а посещаемые сайты видят IP-адрес exit node. Вы просто выбрали другого наблюдателя, поэтому выбирайте того, кому действительно доверяете.

Безопаснее ли Headscale, чем сервер координации Tailscale?

Это другое решение по распределению доверия, а не однозначно более безопасный вариант. При использовании Headscale вы сами храните каталог ключей и policy, поэтому внешняя сторона не сможет принудительно зарегистрировать устройство в вашем tailnet. Однако вы также отвечаете за работу этого сервера: установку обновлений, доступность, резервные копии и безопасность самого хоста. Скомпрометированный хост Headscale даёт атакующему те же возможности по регистрации узлов, что и скомпрометированный сервер координации. Кроме того, tailnet lock отсутствует в списке функций Headscale, поэтому обеспечьте соответствующую защиту этого хоста.

Нужен ли firewall на VPS, который входит в мой tailnet?

Да. Публичный сетевой интерфейс по-прежнему существует, а любой сервис, привязанный к 0.0.0.0, остаётся доступным из Интернета независимо от того, запущен Tailscale или нет. Привязывайте сервисы к адресу tailnet, оставляйте policy по умолчанию с запретом на публичном интерфейсе и проверяйте опубликованные порты контейнеров, поскольку Docker добавляет собственные правила и может открыть порт, который, как вы считали, был закрыт.