Что защищает функция Tailnet lock в Tailscale

Что защищает tailnet lock

Tailnet lock — это функция Tailscale, которая запрещает собственному координационному серверу Tailscale добавлять устройства в вашу сеть tailnet. При включении этой функции ваши узлы отклоняют любой ключ узла, который не был подписан ключом, хранящимся на доверенном вами устройстве. Таким образом, control plane по-прежнему распространяет ключи, но больше не может создавать новых участников. Это ограничение намеренно сделано узким. Tailnet lock защищает процесс присоединения устройства, но никак не влияет на устройство, чей ключ уже был скомпрометирован.

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

Модель угроз в точной формулировке

Ответ tailnet lock заключается в защите от стороны, контролирующей сервер координации. Это включает в себя компрометацию инфраструктуры Tailscale, действия злоумышленника из числа сотрудников или выполнение принудительного предписания, обязывающего Tailscale к каким-либо действиям. Против такого злоумышленника — и только против него — tailnet lock меняет ситуацию: вместо того чтобы «добавить узел», он получает ответ «невозможно, попытка зафиксирована».

Механизм представляет собой цепочку подписей, которой вы владеете. Каждый подписывающий узел локально генерирует ключ tailnet lock key (TLK) и хранит его на устройстве. Ваша сеть tailnet получает лог обновлений полномочий, доступный только для добавления, — tailnet key authority (TKA), и каждый узел хранит собственную копию этого лога. Ключ узла, поступивший без действительной подписи от текущего доверенного TLK, отклоняется, поэтому узел не получает соединения и отображается как заблокированный. В технической документации Tailscale результат описан прямо: инфраструктура Tailscale не может добавить неавторизованный узел в сеть с включенным tailnet lock, а любая попытка сделать это будет обнаружена и заблокирована.

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

• Кража устройства. Подпись лишь подтверждает, что доверенный администратор в какой-то момент одобрил ключ этого узла. Она ничего не говорит о том, кто владеет ноутбуком в данный момент.
• Компрометация подписывающего узла. В списке ограничений Tailscale прямо указано: ключи tailnet lock хранятся на устройстве, поэтому злоумышленник, получивший доступ к устройству, может получить и ключ. Подписывающий узел требует такого же уровня защиты, как и машина, хранящая root SSH-ключ; это та же дисциплина, что описана в генерации, хранении и ротации SSH-ключей.
• Отказ в обслуживании (DoS). В технической документации четко сказано, что tailnet lock защищает от неавторизованных узлов, а не от отказа в обслуживании. Враждебно настроенная панель управления (control plane) по-прежнему может прекратить распространение обновлений и нарушить ваше соединение. Она просто не сможет стать участником сети.
• Первые пять минут. См. следующий раздел, так как это та часть, которую люди обычно пропускают.

Почему tailnet lock основан на принципе доверия при первом использовании

Когда вы включаете tailnet lock, начальный набор доверенных ключей поступает на ваши узлы через control plane — именно ту сторону, доверие к которой вы пытаетесь исключить. Каждый узел принимает полученные данные при первом обращении и в дальнейшем принудительно их использует. В техническом описании Tailscale этот разрыв обозначен: при первом включении tailnet lock каждый узел полагается на начальное состояние, переданное ему от control plane. Если в этот момент control plane уже скомпрометирован, он может внедрить набор ключей, содержащий ключ злоумышленника, и любая последующая подпись будет проходить проверку.

Это принцип доверия при первом использовании (TOFU), аналогичный модели проверки отпечатка SSH-ключа хоста, который вы принимаете при первом подключении. Внешнего авторитета для проверки не существует, поэтому проверка выполняется вручную и является вашей ответственностью.

tailscale lock status

Выполните эту команду на нескольких узлах после включения. Сравните значения tlpub:, которые сообщает каждый узел, с ключами, которые фактически вывели ваши подписывающие узлы. Сравнивайте их через канал связи, не зависящий от tailnet, так как скомпрометированный control plane, внедривший вредоносный набор ключей, может видеть и переписку, которую вы используете для проверки. Это разовая задача, которая занимает десять минут и является единственным барьером, отделяющим вас от блокировки, которая иначе ничего не защищает.

Проверьте это перед включением

• Каждому узлу, который должен продолжать работу, требуется Tailscale v1.46.1 или более поздняя версия — это минимальная версия, указанная в документации Tailscale для tailnet lock. Выполните tailscale version на каждом из них, включая маршрутизатор или устройство, которое вы однажды добавили и забыли.
• Необходимо выбрать как минимум два узла подписи. Это не формальность: ключи подписи хранятся на этих устройствах, поэтому при наличии только одного узла подписи выход из строя одного диска приведет к тому, что вы больше никогда не сможете добавить новое устройство в tailnet.
• Устройство на базе Android не может выступать в роли узла подписи, так как оно не способно выполнять операцию подписи.
• Функции tailnet lock и одобрение устройств (device approval) являются взаимоисключающими. Если в вашем tailnet уже требуется ручное одобрение устройств, вам придется выбрать что-то одно, а не использовать их вместе.
• По состоянию на сентябрь 2026 года в документации Tailscale указано, что tailnet lock доступен в планах Personal и Enterprise, поэтому уточните свой тарифный план, прежде чем гарантировать наличие этого контроля в рамках аудита безопасности.

Как включить tailnet lock

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

1. В консоли администратора откройте страницу управления устройствами (Device management) и выберите включение tailnet lock.
2. Выберите узлы, ключам tailnet lock которых вы доверяете. Выберите как минимум два узла на оборудовании, к которому у вас есть физический доступ.
3. Решите, отправлять ли один секрет для отключения (disablement secret) в службу поддержки Tailscale. Перед принятием решения прочитайте следующий раздел.
4. Скопируйте команду tailscale lock init, которую сгенерирует консоль. Она содержит по одному аргументу tlpub: для каждого выбранного вами подписывающего узла.
5. Выполните её на одном из этих подписывающих узлов.

tailscale lock init "tlpub:SIGNING_NODE_1_KEY" "tlpub:SIGNING_NODE_2_KEY"

Каждый узел, уже находящийся в tailnet, подписывается доверенными ключами во время инициализации, поэтому всё, что работало, продолжает работать. Изменения касаются только новых узлов. Машина, которая присоединяется к заблокированному tailnet, получает неподписанный ключ узла, и команда tailscale lock status на этой машине сообщает об этом:

This node is LOCKED OUT by tailnet-lock, and action is required to establish connectivity.

В консоли администратора это состояние отображается как значок Locked out, а фильтр списка машин property:locked-out позволяет найти их все сразу. Вывод статуса на заблокированном узле также содержит точную команду для исправления ситуации. Скопируйте эту строку и выполните её на подписывающем узле:

tailscale lock sign "nodekey:NODE_KEY" "tlpub:ROTATION_KEY"

Состав подписывающих узлов со временем меняется, и для этого предусмотрены две команды. tailscale lock add tlpub:<key> добавляет доверие к новому подписывающему узлу. tailscale lock remove tlpub:<key> выводит узел из эксплуатации; по умолчанию она переподписывает узлы, которые были подписаны выведенным ключом, чтобы они продолжали работать (это поведение можно отключить с помощью --re-sign=false). Если подписывающий узел был украден, а не просто выведен из эксплуатации, используйте tailscale lock revoke-keys tlpub:<key>. Эта процедура выполняется поэтапно на оставшихся подписывающих узлах с использованием --cosign, а затем --finish. tailscale lock log --limit 20 выводит историю полномочий; именно здесь нужно искать информацию, если узел заблокирован, а никто не помнит, чтобы вносились какие-либо изменения.

Десять секретов отключения и почему они представляют собой зону риска

tailscale lock init выводит десять секретов отключения. Они отображаются один раз, при инициализации, и больше никогда не показываются. Любой из них отключает tailnet lock для всей сети tailnet:

tailscale lock disable "DISABLEMENT_SECRET"

Документация Tailscale прямо указывает на последствия: если вы потеряете секреты отключения и не предоставили один из них в службу поддержки Tailscale, восстановить tailnet будет невозможно. Представьте реальный сценарий. Ваши два узла подписи — это ноутбук, который был стерт, и VPS, который был удален. Никто не может подписать ключ нового узла, никто не может добавить узел подписи и никто не может отключить блокировку. Tailnet продолжает работать для существующих участников, но не принимает новых, навсегда. Единственный выход — создание новой сети tailnet и повторная регистрация всех устройств.

Поэтому храните секреты как коды восстановления, которыми они и являются. Имейте как минимум две копии в местах, которые не зависят от доступности tailnet, и храните одну из них в офлайне. Копия, которая находится только на сервере, доступном через tailnet, не является резервной копией.

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

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

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

AUTH_KEY="tskey-auth-xxxxxxxxxxxxxxxx"
tailscale lock sign $AUTH_KEY

Запустите это на узле, имеющем права на подписание. Команда выведет подписанную версию ключа аутентификации, и именно это подписанное значение ваш образ, файл cloud-init или переменная Terraform должны передать в tailscale up --auth-key. Любой узел, созданный с таким ключом, изначально будет подписан и доступен.

Стоит знать о двух режимах сбоя, прежде чем вы с ними столкнетесь. Во-первых, процесс подписания плохо работает при параллельном выполнении. В проблеме 15266 в репозитории tailscale/tailscale, открытой в марте 2025 года, описываются запуски Terraform, где параллельные вызовы tailscale lock sign возвращали пустые подписанные ключи, из-за чего часть узлов оказывалась заблокированной, а остальные работали нормально. Временным решением для автора было подписание ключей по одному с небольшой паузой между вызовами. Настройте автоматизацию так, чтобы она проверяла, что команда вернула непустой ключ, прежде чем сохранять его.

Во-вторых, подписанные ключи аутентификации оставляют после себя состояние. Подписание добавляет ключ в центр сертификации (authority), и этот ключ остается там даже после того, как созданный им узел исчезает. В проблеме 16607 от июля 2025 года описывается автоматизация, которая подписывала новый ключ для каждого развертывания, пока центр сертификации не достиг своего лимита:

network-lock modify failed: modify network-lock keys: generating checkpoint: generated update was invalid: checkpoint state: too many keys (552, max 512)

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

Эфемерные узлы и CI-узлы требуют планирования

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

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

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

Два способа аварийного восстановления и их назначение

tailscale lock disable <disablement-secret> отключает tailnet lock для всей сети tailnet. Для этого требуется один из десяти секретных ключей; этот способ используется, когда проблема заключается в самой системе авторизации.

tailscale lock local-disable

tailscale lock local-disable — это способ восстановления на уровне отдельного узла, назначение которого часто понимают неверно. Он отключает принудительное использование tailnet lock на том узле, где выполняется команда, позволяя этому узлу принимать узлы с неподписанными ключами. Это не заставляет другие узлы принимать неподписанный ключ данного узла. Если сервер заблокирован, он не станет доступным только из-за того, что вы выполнили на нём local-disable. Именно поэтому в документации Tailscale рекомендуется выполнять эту команду на каждом узле, чтобы фактически игнорировать tailnet lock во всей сети tailnet. Используйте это как экстренную меру для узла, который невозможно подписать в данный момент, а затем выполните корректное подписание и снова включите принудительную проверку.

Кому следует включить tailnet lock, а кому не стоит

Включите эту функцию, если необходимо, чтобы процесс добавления узлов оставался безопасным даже после ухода сотрудников. Без блокировки любой пользователь с правами администратора в консоли может добавить устройство. При включенном режиме lock для добавления машины также требуется устройство, обладающее доверенным ключом подписи. Таким образом, уволенный администратор, чей доступ к консоли вы забыли отозвать, не сможет добавить свой узел. Включите эту функцию, если в анкете оценки рисков сторонних поставщиков (third-party-risk questionnaire) у вас спрашивают, что мешает провайдеру VPN подключиться к вашей сети: это средство контроля позволяет ответить на вопрос с помощью технического механизма, а не простого обещания.

Не включайте эту функцию для tailnet, состоящей из одного пользователя с ноутбуком, телефоном и VPS. Реальная угроза для такой сети — это потеря доступа к ней вами, а не компрометация Tailscale. Tailnet lock добавляет десять секретов, которые вы обязаны хранить надежно и вечно. Их потеря необратима, поэтому функция повышает риск, с которым вы реально сталкиваетесь, ради снижения риска, который для вас неактуален. Тот же аргумент применим к небольшой команде, где нет четкого учета того, у кого находятся устройства для подписи. Сначала наведите порядок в этом учете, так как tailnet lock — это процесс управления ключами с риском безвозвратной потери доступа при ошибке.

Headscale предлагает другой ответ на тот же вопрос

Если возражение заключается в том, что третья сторона решает, кто входит в вашу сеть, существует два ответа. Tailnet lock ограничивает сервер координации Tailscale и лишает его возможности добавлять новых участников. Запуск Headscale, сервера координации с открытым исходным кодом, который вы размещаете самостоятельно полностью исключает сторонний сервер, но вы берете на себя как полномочия, так и всю работу по его обслуживанию: установку обновлений, создание резервных копий и устранение сбоев, которые вам придется исправлять в два часа ночи. Ни один из вариантов не является более безопасным в абстрактном смысле. Выбирайте исходя из того, какой тип отказа вы готовы взять на себя: управляемую вами облачную панель с ограничениями или панель управления, которую вы обслуживаете самостоятельно.

FAQ

Что именно блокирует tailnet lock?

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

Что произойдет, если я потеряю все десять секретов отключения?

Секреты отображаются один раз при запуске tailscale lock init и больше никогда не показываются. Если вы потеряли их все и не передали один из них в поддержку Tailscale, согласно документации, восстановить tailnet невозможно. На практике, если вы также потеряете свои подписывающие узлы, вы не сможете подписать новый ключ узла и отключить блокировку. Единственный выход — создать новую tailnet и заново зарегистрировать все устройства. Храните две копии в местах, доступ к которым не зависит от работоспособности tailnet, и держите одну из них в офлайне.

Нужно ли подписывать каждое новое устройство вручную?

Нет. Подписывайте ключ авторизации (auth key) вместо самого узла. На подписывающем узле экспортируйте ключ и выполните tailscale lock sign $AUTH_KEY, затем передайте подписанное значение, которое выведет команда, в tailscale up --auth-key в вашем образе или инструменте подготовки инфраструктуры. Узлы, созданные таким образом, будут уже подписаны. Подписывайте небольшое количество многоразовых ключей, а не по одному на машину, так как каждый подписанный ключ добавляет запись в центр сертификации, которая остается даже после удаления узла. У центра сертификации есть ограничение в 512 ключей, и автоматизация уже сталкивалась с этим пределом на практике.

Является ли tailnet lock тем же самым, что и одобрение устройств (device approval)?

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