Чи безпечний Tailscale: модель довіри

Чи безпечний Tailscale? Коротка відповідь

Чи безпечний Tailscale? Якщо йдеться про те, що найбільше турбує більшість користувачів, то так: coordination server, який обслуговує ваш tailnet, ніколи не зберігає приватні ключі, якими шифрується трафік. Тому він не може прочитати дані, якими ваші пристрої обмінюються між собою. На сторінці безпеки Tailscale це сформульовано прямо: "Private keys never leave the device. All traffic is end-to-end encrypted, always." Корисніше поставити інше запитання. Coordination server, який було скомпрометовано або роботу якого зобов’язали розкрити за судовим рішенням, не повинен читати ваші пакети. Він визначає, яким відкритим ключам довіряють ваші пристрої, тому може додати пристрій, який ви не схвалювали.

Ось модель довіри в одному реченні: шифрування захищає дані, а control plane визначає склад мережі. У кожному розділі нижче названо одну зі сторін, якій потрібно довіряти, описано, що саме ця сторона може зробити, і наведено засіб контролю, який обмежує її можливості. Якщо продукт вам ще не знайомий, почніть із матеріалу що таке Tailscale і як працює його mesh.

Площина керування та площина даних відокремлені

Tailscale — це mesh VPN (віртуальна приватна мережа) на основі WireGuard, того самого протоколу, який можна налаштувати вручну на власному WireGuard VPS. Кожен пристрій локально генерує власну пару ключів WireGuard. У дописі Tailscale як це працює сервер координації названо «спільною скринькою для відкритих ключів». Там також зазначено: «Приватний ключ ніколи не залишає свій вузол».

Площина даних — це зашифрований трафік між вашими пристроями. Він передається безпосередньо від пристрою до пристрою, якщо це дозволяє мережа. Площина керування — це все інше: які пристрої належать до tailnet, який відкритий ключ відповідає кожному пристрою, політика доступу, налаштування DNS і список relay-серверів. Tailscale надає площину керування як hosted-сервіс. Площину даних ви запускаєте на власних машинах.

Розділяйте ці дві площини, і на кожне питання безпеки можна буде відповісти. Шифрування є властивістю площини даних. Належність до мережі визначається площиною керування. Жодне шифрування не визначає, кому дозволено бути peer.

Що може зробити скомпрометований coordination server?

Він не може розшифрувати ваш трафік. Ключі шифрування генеруються на ваших пристроях і ніколи не передаються на сервер. Тому їх неможливо вилучити або витік якихось даних із ними не відкриє тунель. Це також стосується трафіку через relay, про який ідеться далі.

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

Він може змінити перелік ресурсів, до яких дозволено доступ із ваших пристроїв. Політика доступу зберігається в control plane і поширюється на вузли. У white paper Tailscale про tailnet lock зазначено, що tailnet lock «не запобігає порушенню з’єднань у вашій мережі скомпрометованим control plane, наприклад через непоширення ключів нових вузлів або поширення політики контролю доступу, яка забороняє доступ до всіх вузлів».

У будь-якому разі він бачить метадані з’єднань. Мережеві flow logs Tailscale записують події відкриття та закриття кожного з’єднання між машинами. У документації зазначено, що ці журнали «категорично не містять жодної інформації про операції клієнта або вміст мережевого трафіку». Отже, control plane може знати, який із ваших пристроїв обмінювався даними з іншим і коли. Він не знає, що саме вони передавали.

Лише один пункт у цьому списку стосується шифрування. Інші стосуються того, хто входить до tailnet і що визначає політика. Саме тому слід приділити увагу засобам контролю, які керують додаванням вузлів.

Ваш identity provider є коренем довіри для tailnet

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

Сприймайте це як твердження про безпеку, адже так воно і є. Той, хто може увійти у ваш обліковий запис Google або Microsoft, може увійти у ваш tailnet. Багатофакторна автентифікація (MFA) визначається політиками IdP. Процедура деактивації доступу після звільнення працівника визначається діями IdP. Скомпрометований обліковий запис IdP дає доступ до tailnet, а зловмиснику не потрібно атакувати WireGuard: він додає пристрій і отримує всі дозволи, які ваша політика надає цьому користувачу.

Між викраденим обліковим записом і працездатним пристроєм усередині tailnet діють два засоби контролю: схвалення пристрою та завершення терміну дії ключа. Tailnet lock є третім засобом і спрямований на control plane, а не на обліковий запис.

Схвалення пристроїв: нічого не підключається, доки людина не підтвердить

Документація Tailscale описує схвалення пристроїв як функцію, яка «дає адміністраторам мережі Tailscale змогу перевіряти та схвалювати нові пристрої, перш ніж вони зможуть підключитися до вашої мережі Tailscale». Схвалити пристрій може Owner, Admin або IT admin. На сторінці Machines біля нового пристрою відображається позначка «Needs approval», доки хтось не виконає потрібну дію.

Увімкніть цю функцію, і сценарій із викраденням облікового запису зміниться. Зловмисник входить до облікового запису, пристрій реєструється, а потім очікує без можливості отримати доступ до будь-яких ресурсів. У консолі адміністратора поруч відображається позначка, яка повідомляє, що невідомий вам пристрій намагається підключитися. Автоматизація продовжує працювати, оскільки під час створення auth key можна позначити як попередньо схвалений, а пристрої можна схвалювати через API.

Auth keys — це інший спосіб підключення, тому поводьтеся з ними як з обліковими даними. Документація Tailscale прямо попереджає про найризикованіший тип: «Будьте дуже обережні з багаторазовими ключами! У разі викрадення вони можуть бути дуже небезпечними. Найкраще зберігати їх у продукті key vault, спеціально призначеному для цього». Станом на August 2026 задокументований строк дії ключа становить від 1 до 90 days, а якщо строк дії не вказано, за замовчуванням використовується максимальне значення 90 days. Надавайте перевагу одноразовим ключам, позначайте їх як ephemeral для машин, які часто підключаються та відключаються, а багаторазові ключі зберігайте у зашифрованому вигляді за допомогою Ansible Vault або в secrets manager, а не в shell script.

Термін дії ключа: таймер, який обмежує наслідки всіх інших помилок

Термін дії ключів Node спливає, і це перетворює викрадений або забутий пристрій на тимчасову проблему. У документації Tailscale зазначено: «За замовчуванням для нових доменів установлено період дії 180 днів», а також: «Якщо повторна автентифікація не відбувається, термін дії ключів спливає, і з’єднання із зазначеною кінцевою точкою та від неї припиняють працювати». Повторно автентифікувати пристрій можна вручну:

tailscale up --force-reauth

У документації попереджається, що це «може перервати з’єднання з tailnet, тому не слід виконувати цю дію віддалено через SSH або RDP без альтернативного способу входу на випадок втрати з’єднання». Виконуйте команду, маючи відкритий доступ до консолі, або використовуйте другий канал доступу до машини, оскільки мережеве з’єднання, яким ви користуєтеся, буде перервано.

На серверах цей механізм часто вимикають. Машина, яка має повторно автентифікуватися кожні 180 днів, о 3am вийде з tailnet, коли ніхто не контролює її стан, тому адміністратори вимикають для неї завершення терміну дії ключа. У такому разі зникає таймер, який зрештою заблокував би викрадений ключ. Для сервера кращим рішенням є пристрій із тегом: тег прив’язує машину до організації, а не до конкретної людини, тому машина продовжує працювати після звільнення працівника. Незалежно від рішення, ведіть список машин, для яких вимкнено завершення терміну дії: такі ключі залишаються чинними, доки ви не видалите пристрій.

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 вмикає цю функцію, і в цей момент ви призначаєте signing nodes. Під час ініціалізації Tailscale вимагає щонайменше два signing nodes і дозволяє не більше 20 у tailnet. Після цього кожен новий пристрій має отримати підпис від одного з них. Це створює реальні операційні витрати: щоб додати телефон, потрібно виконати команду на ноутбуці.

Обмеження задокументовані, і вони важливіші за опис функції:

• Якщо втратити disablement secret, відновлення неможливе. У документації зазначено: «Якщо ви втратили disablement secrets і не передали жоден із них до служби підтримки Tailscale, tailnet неможливо відновити».
• Signing key зберігається на пристрої, яким ви володієте, тому його безпека залежить від безпеки цього пристрою. У документації прямо зазначено: «Якщо пристрій скомпрометовано, ключ можна отримати».
• Не можна одночасно використовувати обидва механізми контролю. Tailscale зазначає, що tailnet lock і device approval є взаємовиключними. Увімкнення одного з них означає відмову від іншого.
• Це модель довіри під час першого використання (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. Це дає змогу визначити, яка з цих двох причин виникла. Якщо peer уже має пряме з’єднання, але пропускна здатність усе одно низька, проблема не в relay. Найчастіше причиною повільної роботи WireGuard є невідповідність path MTU.

Вузол виходу переміщує вашу точку виходу, але не усуває її

Вузол виходу маршрутизує весь публічний інтернет-трафік пристрою через інший пристрій у 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. Такий самий етап схвалення застосовується до маршрутів підмереж: машина, яка оголошує приватний діапазон, не працює, доки адміністратор його не прийме. Це перша перешкода під час оголошення приватної мережі для вашого tailnet з VPS.

Тепер питання довіри. Трафік шифрується від вашого ноутбука до вузла виходу. Після цього він залишає цю машину як звичайний інтернет-трафік і містить IP-адресу цієї машини. Тому оператор вузла виходу бачить адреси призначення. Їх також бачать хостинг-провайдер цієї машини та її upstream-мережа. Ви перемістили точку спостереження, а не усунули її. Це виправданий компроміс, якщо ви контролюєте віддалений кінцевий вузол. Саме це є аргументом на користь запуску власного вузла виходу на VPS. Якщо ви не контролюєте його, такий компроміс невдалий.

Типова політика — пласка мережа

Новий tailnet працює з permissive-політикою. У документації 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, а також перегляньте що насправді входить до free plan. Для пристрою, який взагалі не повинен приймати вхідні підключення, наприклад особистого телефона, tailscale set --shields-up блокує їх на стороні клієнта.

Що змінюється, якщо розмістити control plane з Headscale у власній інфраструктурі

Headscale — це «open source реалізація control server Tailscale, яку можна розмістити у власній інфраструктурі». У README чесно визначено сферу застосування: «Реалізація має вузьку сферу: одну мережу Tailscale (tailnet), придатну для особистого використання або невеликої open-source організації». До переліку функцій входять ACL і grants, subnet routers, exit nodes, вбудований DERP server, Tailscale SSH і Taildrop. Якщо саме вузька сфера застосування є проблемою, NetBird — інша mesh-система з control plane, який можна розмістити у власній інфраструктурі, а розміщення NetBird server на власному VPS переносить те саме рішення щодо реєстрації на обладнання, яким ви володієте.

Змінюється ідентифікація сторони, яка могла б зареєструвати несанкціонований вузол. У Headscale каталог ключів і політика зберігаються на вашому сервері. Жодна третя сторона не зберігає список публічних ключів ваших пристроїв. Також жодну третю сторону не можна змусити передати такий ключ або підписати його.

Площина передавання даних не змінюється. Використовується той самий WireGuard із тим самим end-to-end шифруванням і тим самим резервним переходом на relay, коли прямий шлях недоступний. Ви також берете на себе завдання, які раніше виконував Tailscale: забезпечення доступності, встановлення оновлень, резервне копіювання та фізичний захист сервера. Якщо цей сервер є орендованим VPS, останній пункт залежить від обіцянок іншої сторони, а не від вашого контролю, оскільки hypervisor може прочитати пам’ять гостьової системи, а разом із нею — каталог ключів, якщо обладнання не підтримує зашифровану пам’ять, яку можна атестувати. Скомпрометований Headscale host дає зловмиснику саме те, що дає скомпрометований coordination server: можливість зареєструвати вузол і поширити політику. Tailnet lock не входить до переліку функцій Headscale, тому відповідний компенсувальний контроль там недоступний. Вартість також може вплинути на вибір деяких tailnet, оскільки Tailscale стягує плату за користувача, а не за пристрій, і ця арифметика змінюється, щойно невелика команда перевищує ліміти безкоштовного плану. Якщо вирішальним для вас є питання контролю, розміщення control plane з Headscale у власній інфраструктурі описує процес налаштування.

Від чого захищає Tailscale

• Відкриті порти, на яких прослуховуються сервіси. Сервіс, прив’язаний до адреси tailnet, недоступний з інтернету, тому сканери, які перевіряють кожен VPS на порту 22, його не побачать. Виняток потрібно вмикати самостійно: Funnel навмисно публікує сервіс tailnet у відкритому інтернеті. Тому перед виконанням будь-якої з цих команд варто знати де закінчується serve і починається funnel. Усе одно залиште host firewall увімкненим, оскільки опублікований порт Docker створює власні правила та обходить ufw на публічному інтерфейсі.
• Підбір паролів для відкритих облікових записів. Якщо порт відповідає лише всередині тунелю, підбирати пароль неможливо. Це надійніший варіант, ніж обмежувати швидкість запитів до відкритого порту. Водночас fail2ban на Ubuntu 24.04 усе одно варто запустити для сервісів, які мають залишатися публічними.
• Недовірені мережі на шляху передавання. Трафік між вашими машинами шифрується наскрізно під час передавання через мережу кафе або спільну LAN-мережу провайдера. Якщо трафік передається через relay, він також залишається зашифрованим.
• Ручне розповсюдження ключів. Кожен вузол, який вручну додають до конфігурації WireGuard, створює ризик повторно використати адресу або вставити неправильний ключ. Mesh-мережа веде ці дані замість вас. Саме це є основною практичною відмінністю у порівнянні WireGuard і Tailscale.

Чого Tailscale не захищає

• Скомпрометований кінцевий пристрій. Tailnet довіряє пристроям. Шкідливе програмне забезпечення на схваленому ноутбуці отримує тунель, адреси tailnet і все, що дозволяє політика для цього користувача. Це найбільша прогалина, і жоден VPN її не усуває.
• Зловмисний або недбалий адміністратор. Той, хто може редагувати файл політики, може надати собі доступ до будь-чого. Те саме може зробити той, хто захопить обліковий запис ідентифікації Owner. Перевіряйте зміни політики так само, як перевіряєте код.
• Аналіз мережевого трафіку. Ваш ISP (інтернет-провайдер) бачить зашифрований 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. Це свідчить про їхні процеси, а не про конфігурацію вашого tailnet.

FAQ

Чи може Tailscale читати мій трафік?

Ні. Трафік шифрується за допомогою ключів WireGuard, які генеруються на ваших пристроях. На сторінці безпеки Tailscale зазначено: «Приватні ключі ніколи не залишають пристрій. Увесь трафік завжди має наскрізне шифрування». Це також стосується з’єднань, які переходять на ретранслятор DERP, оскільки ретранслятор «безпосередньо пересилає вже зашифрований трафік від одного пристрою до іншого» і не має ключа для його розшифрування. Інфраструктура Tailscale бачить метадані: які пристрої існують, які з них з’єднувалися між собою та коли це відбувалося.

Що насправді може зробити скомпрометований сервер координації Tailscale?

Він може додати вузол. У власному повідомленні Tailscale про tailnet lock описано ризик приховано доданого вузла, який може «надсилати трафік на наявні вузли або отримувати трафік від них». Шифрування в цьому випадку не допомагає, «оскільки сам одноранговий вузол може бути зловмисним». Скомпрометований control plane також може поширити політику, яка змінить доступ пристроїв, а в white paper про tailnet lock зазначено, що він може порушити з’єднання, не поширивши нові ключі вузлів. Він не може розшифрувати трафік між наявними пристроями, оскільки ніколи не мав їхніх приватних ключів.

Чи приховує exit node мою історію перегляду від ISP?

Він приховує призначення від мережі, до якої ви підключені, зокрема від домашнього або кафе ISP, оскільки весь трафік залишає ваш пристрій у зашифрованому вигляді та адресований exit node. Це не робить вас анонімними. Тепер ці призначення бачить exit node, а також його хостинг-провайдер і upstream-мережа. Сайти, які ви відвідуєте, бачать IP-адресу exit node. Ви просто обрали іншого спостерігача, тому обирайте того, кому справді довіряєте.

Чи є Headscale безпечнішим за сервер координації Tailscale?

Це інше рішення щодо довіри, а не гарантовано безпечніший варіант. У Headscale ви керуєте каталогом ключів і політикою, тому стороння організація не може змусити додати пристрій до вашого tailnet. Водночас ви відповідаєте за роботу цього сервера: встановлення патчів, доступність, резервні копії та безпеку самого хоста. Скомпрометований хост Headscale надає зловмиснику такі самі можливості додавати пристрої, як і скомпрометований сервер координації. Tailnet lock не входить до переліку функцій Headscale, тому належно захищайте цей хост.

Чи потрібен мені firewall на VPS, який входить до мого tailnet?

Так. Публічний мережевий інтерфейс усе ще існує, а будь-який сервіс, прив’язаний до 0.0.0.0, залишається доступним з інтернету незалежно від того, чи запущено Tailscale. Прив’язуйте сервіси до адреси tailnet, залишайте політику заборони за замовчуванням на публічному інтерфейсі та перевіряйте опубліковані порти контейнерів, оскільки Docker додає власні правила й може відкрити порт, який, на вашу думку, був закритий.