Если устройство удалено из панели Tailscale или ZeroTier, но по-прежнему открывает серверы и внутренние сервисы, сначала нужно доказать, что новый трафик действительно идет через удаленный узел частной сети. Доступ может сохраняться по публичному IP, локальной сети, через subnet router, старую прикладную сессию или повторно зарегистрированный узел.

Удаление записи по имени не всегда означает отзыв всех связанных способов входа. Устройство может появиться в панели заново с другим идентификатором, если на нем остался reusable auth key, OAuth-провижининг или интерактивная авторизация, а обязательное одобрение новых устройств отключено.

Сначала убедитесь, что доступ действительно сохранился

Проверяйте новое соединение после удаления, а не только уже открытое окно терминала или старую запись мониторинга. Зафиксируйте точный адрес назначения, порт, время и исходный IP, который видит сервер.

  • Закройте существующую SSH, RDP или web-сессию и создайте новое подключение.
  • Сравните адрес сервиса: overlay IP, MagicDNS-имя, локальный адрес или публичный домен.
  • Посмотрите source IP в журнале сервера, reverse proxy, firewall или приложения.
  • Проверьте, не доступен ли тот же сервис напрямую из интернета или локальной сети.
  • Уточните, не проходит ли трафик через другой разрешенный subnet router или gateway.

Если сервер видит обычный публичный адрес, удаление узла из mesh VPN не закроет этот маршрут. Нужно отдельно исправлять firewall, учетную запись сервиса, SSH-ключ, API-токен или активную прикладную сессию.

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

Удалена не та запись устройства

Hostname не является надежным идентификатором. После переустановки, клонирования виртуальной машины или повторной авторизации в панели могут появиться несколько похожих записей с одинаковым именем, но разными machine ID, node ID, владельцами и ключами.

  • Сверьте уникальный идентификатор узла, пользователя, теги, ОС и время last seen.
  • Найдите дубли hostname и записи, появившиеся сразу после удаления.
  • Проверьте, принадлежит ли активный overlay IP именно удаленной записи.
  • Для ZeroTier сравнивайте member или node ID, а не только заданное имя.

Устройство автоматически регистрируется заново

Удаление Tailscale-устройства отзывает его текущий node key и должно почти сразу отключить его от ресурсов tailnet. Но при выключенном device approval клиент может снова пройти авторизацию. Автоматизация также может повторно зарегистрировать узел с reusable auth key или OAuth credentials.

  • Проверьте startup scripts, cloud-init, контейнерные переменные и секреты CI/CD.
  • Найдите reusable или pre-approved auth keys, которыми мог пользоваться клиент.
  • Проверьте OAuth clients и сервисные процессы, создающие новые auth keys.
  • Включите обязательное одобрение новых устройств, если процесс эксплуатации это допускает.

Отозван ключ регистрации, но не сам узел

Auth key используется для добавления устройства, а node key — для его текущей работы в Tailscale. Отзыв исходного auth key не деавторизует уже зарегистрированный узел. Для прекращения доступа нужно удалить конкретное устройство в Machines и проверить, не появилось ли оно снова.

Доступ выдан через другую сущность

Узел может быть tagged device, shared machine, subnet router или членом другой частной сети. Удаление пользователя либо одной записи не всегда затрагивает отдельную сервисную идентичность, маршрут или опубликованный ресурс.

  • Проверьте владельца узла и все назначенные теги.
  • Просмотрите grants, ACL и правила доступа к конкретному адресу и порту.
  • Проверьте shared devices и приглашения между сетями.
  • Найдите advertised routes, exit nodes и отдельные gateways до целевой подсети.

Панель и фактический control plane не совпадают

В self-hosted или смешанной схеме можно удалить участника не в том контроллере, организации либо network ID. Также интерфейс может показывать старое состояние из кеша, поэтому решение нужно подтверждать журналом API и новым сетевым тестом.

Пошаговая безопасная диагностика

  1. Зафиксируйте инцидент: имя устройства, уникальный node ID, пользователя, теги, overlay IP, время удаления и целевой ресурс.
  2. На целевом сервере определите source IP нового соединения и маршрут, по которому оно пришло.
  3. В панели найдите все записи с тем же hostname, пользователем, тегами и недавним last seen.
  4. Проверьте журнал административного удаления или ответ API, чтобы исключить ошибку интерфейса и неверный объект.
  5. Просмотрите auth keys, OAuth clients, startup scripts и секреты автоматического провижининга.
  6. Проверьте ACL, grants, shares, route approvals, subnet routers и публичные правила firewall для нужного сервиса.
  7. Временно закройте доступ на уровне самого ресурса для подозрительной идентичности и убедитесь, что новые попытки блокируются.
  8. После исправления повторите тест с удаленного устройства, из разрешенного устройства и через прямой публичный адрес.

Как немедленно ограничить доступ

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

  1. Удалите или деавторизуйте точный node ID в правильной организации и сети.
  2. Добавьте временный deny для связанного пользователя, тега, устройства или адреса в политике доступа.
  3. Отзовите reusable auth keys и OAuth credentials, которые могли повторно регистрировать устройство.
  4. Отключите учетную запись пользователя либо завершите ее активные сессии, если устройство имело прикладной вход.
  5. Замените SSH-ключи, API-токены и другие секреты, которые могли храниться на устройстве.
  6. Закройте прямой публичный доступ к сервису или ограничьте его известными источниками.
  7. Включите device approval и проверьте очередь новых узлов перед их допуском.

Не публикуйте в тикетах auth keys, private keys, recovery codes и полные конфигурации доступа. Для проверки достаточно идентификаторов, времени событий, безопасных fingerprints и обезличенных правил.

Как исправить причину, а не только симптом

  • Назначьте каждому устройству однозначного владельца или сервисный тег с минимальными правами.
  • Замените общие reusable keys на одноразовые, короткоживущие или ephemeral-механизмы там, где это возможно.
  • Храните ключи провижининга в secret storage и ограничивайте доступ к ним отдельной ролью.
  • Используйте default deny и выдавайте доступ только к нужным адресам и портам.
  • Разделите пользовательские устройства, серверы, subnet routers и CI-агенты по разным политикам.
  • Автоматизируйте offboarding: удаление узлов, отзыв shares, закрытие прикладных сессий и ротацию секретов.
  • Для self-hosted control plane документируйте точный URL контроллера, organization и network ID каждого окружения.

Как проверить, что доступ действительно закрыт

  • Удаленное устройство не создает новое соединение к overlay IP и закрытым портам.
  • В панели нет второго узла с тем же hostname или новой регистрацией после удаления.
  • Попытка повторного входа требует авторизации и административного одобрения.
  • На сервере отсутствуют успешные подключения от прежнего overlay и публичного источника.
  • Разрешенные устройства продолжают работать, а subnet routes не получили лишнего простоя.
  • Отозванные прикладные токены, SSH-ключи и сессии больше не принимаются.
  • Алерты фиксируют попытку повторной регистрации или обращение к закрытому ресурсу.

Типичные ошибки

  • Удалять устройство только по hostname, не проверяя уникальный ID и дубли.
  • Отзывать auth key и считать, что все ранее добавленные им узлы деавторизованы.
  • Удалять клиента локально, но оставлять его активную запись в control plane.
  • Проверять доступ по старой открытой сессии вместо нового соединения.
  • Закрывать DNS-имя, сохраняя прямой публичный IP и действующие учетные данные.
  • Игнорировать tagged nodes, shares и subnet routers при отзыве пользователя.
  • Проводить проверку отключением всего firewall и создавать более широкий риск.
  • Оставлять reusable key в образе виртуальной машины, контейнере или истории команд.

Как предотвратить повторение

  • Включите device approval и регулярно проверяйте недавно добавленные устройства.
  • Настройте ограниченный срок ключей там, где это не ломает серверные процессы.
  • Используйте отдельные теги и минимальные grants для инфраструктурных узлов.
  • Добавьте уведомления об удалении, регистрации, смене владельца и появлении нового маршрута.
  • Проводите периодическую сверку панели, identity provider, CMDB и фактически активных узлов.
  • Подготовьте проверяемый offboarding-чеклист для сотрудников, подрядчиков и утраченных устройств.
  • Не полагайтесь только на VPN: защищайте сам сервис аутентификацией, журналированием и минимальными правами.

Когда нужна помощь

Если удаленное устройство продолжает получать доступ, я проверю фактический маршрут, node ID, повторную регистрацию, auth keys, ACL, shares и subnet routers. Затем закрою лишний путь, настрою безопасный отзыв устройств и проверю, что разрешенные узлы продолжают работать без раскрытия ключей и остановки всей сети.