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

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

Чи безпечний Tailscale? Щодо того, що найбільше непокоїть людей, відповідь — так: coordination server, який обслуговує ваш tailnet, ніколи не зберігає приватні ключі, що шифрують ваш трафік, тому не може читати дані, які ваші пристрої надсилають один одному. На сторінці безпеки Tailscale це сформульовано прямо: "Приватні ключі ніколи не залишають пристрій. Увесь трафік завжди зашифрований наскрізним шифруванням." Важливим є інше питання. Coordination server, який було скомпрометовано або роботу якого зобов’язали розкрити за судовим рішенням, не потребує читати ваші пакети. Він визначає, яким відкритим ключам довіряють ваші пристрої, тому може додати пристрій, який ви не схвалювали.

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

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

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

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

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

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

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

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

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

Він може бачити метадані з’єднань і записувати їх у журнали. Network flow logs у Tailscale за замовчуванням вимкнені й доступні лише в планах Premium та Enterprise. Після ввімкнення адміністратором вони записують лічильники трафіку, зібрані за 5-секундні інтервали: протокол, джерело, призначення, а також кількість пакетів і байтів у кожному напрямку. У журнал потрапляють лише успішні з’єднання. Детальні дані про окремі з’єднання навмисно не збираються. У документації Tailscale щодо журналювання зазначено, що ці журнали «категорично не містять інформації про операції клієнта або вміст network traffic». Отже, з увімкненими flow logs Tailscale може знати, який із ваших пристроїв взаємодіяв з іншим і коли. Вміст цих повідомлень йому невідомий.

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

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

Auth keys — це інший спосіб підключення, тому поводьтеся з ними як з обліковими даними. Документація Tailscale прямо попереджає про найризикованіший тип: «Будьте дуже обережні з багаторазовими ключами! У разі викрадення вони можуть бути дуже небезпечними. Найкраще зберігати їх у продукті для сховища ключів, спеціально призначеному для цього». Станом на October 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: вилучення сервера координації з ланцюжка довіри

Tailnet lock безпосередньо вирішує проблему реєстрації пристроїв. У документації Tailscale про tailnet lock описано механізм: «Коли новий вузол приєднується до tailnet, його відкритий ключ вузла має отримати підпис від ключа Tailnet Lock. Сервер координації поширює підписаний відкритий ключ вузла серед вузлів-пірів». Наявні пристрої перевіряють цей підпис перед прийняттям піра. Тому ключ вузла, який control plane створив самостійно, буде відхилено.

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

tailscale lock init вмикає цю функцію, і в цей момент ви призначаєте вузли підпису. Процедура ввімкнення в адміністративній консолі пропонує вибрати щонайменше два вузли підпису, тоді як довідник CLI Tailscale показує запуск tailscale lock init з одним довіреним ключем. Цей ключ має містити ключ вузла, на якому ви виконуєте команду. У tailnet може бути не більше 20 вузлів підпису. Після цього кожен новий пристрій має отримати підпис від одного з них. Це створює реційні витрати: щоб додати телефон, потрібно виконати команду на ноутбуці.

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

• У разі втрати секрету вимкнення відновлення неможливе. У документації зазначено: «Якщо ви втратили секрети вимкнення і не передали один із них до служби підтримки Tailscale, tailnet неможливо відновити».
• Ключ підпису зберігається на пристрої, яким ви володієте, тому рівень його захисту залежить від безпеки цього пристрою. У документації прямо зазначено: «Якщо пристрій скомпрометовано, ключ можна отримати».
• Одночасно використовувати обидва механізми не можна. Tailscale зазначає, що tailnet lock і схвалення пристроїв є взаємовиключними. Увімкнення одного механізму означає відмову від іншого.
• Це модель довіри під час першого використання (TOFU). Початкове налаштування все одно проходить через control plane. Якір довіри переміщується у вашу власну мережу лише після цього першого кроку.

Tailnet lock захищає склад учасників. Він не захищає доступність, і в white paper це прямо зазначено.

Чи розкриває ретрансльоване з’єднання мій трафік?

Ні. Якщо два пристрої не можуть напряму зв’язатися один з одним, трафік проходить через сервер DERP (Designated Encrypted Relay for Packets). У документації Tailscale це сформульовано однозначно: «Оскільки приватні ключі Tailscale ніколи не залишають локальний пристрій, на якому їх створено, сервер DERP не може розшифрувати ваш трафік. Сервер DERP прозоро пересилає вже зашифрований трафік від одного пристрою до іншого».

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

tailscale status
tailscale netcheck

tailscale status позначає тип з’єднання лише для активних вузлів. Активний вузол виводиться як direct разом з адресою, до якої встановлено з’єднання, наприклад direct 203.0.113.10:41641, як relay разом із назвою ретранслятора в лапках, наприклад relay "fra", або як peer-relay разом з адресою ретранслятора вузла; після проходження трафіку за цим записом також відображаються лічильники байтів tx і rx. Неактивний вузол відображається як idle, offline або просто -, без позначення прямого з’єднання чи ретрансляції. Тому перед перевіркою цього рядка надішліть вузлу певний обсяг трафіку. Якщо вузол постійно працює через ретранслятор, це означає, що кінцеві вузли не змогли побудувати прямий шлях. Зазвичай причина полягає в блокуванні UDP десь на маршруті або в тому, що обидві сторони перебувають за суворим NAT (network address translation). tailscale netcheck показує, чи працює UDP на цій машині взагалі, як NAT зіставляє порти та яка затримка до найближчих ретрансляторів. Це дає змогу визначити, яка з цих двох причин є актуальною. Та сама технологія NAT traversal, яка визначає вибір між прямим шляхом і ретранслятором, дає змогу домашньому NAS або Raspberry Pi працювати без перенаправлення порту на маршрутизаторі. У матеріалі як використовувати Tailscale замість перенаправлення портів описано принцип роботи цієї схеми та її обмеження. Якщо вузол уже підключений напряму, але пропускна здатність усе одно низька, проблема не в ретрансляторі. Зазвичай причиною повільної роботи WireGuard є невідповідність path MTU, описана в матеріалі невідповідність path MTU як типова причина повільної роботи WireGuard.

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

Вузол виходу маршрутизує весь публічний інтернет-трафік пристрою через інший пристрій у 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 у консолі адміністрування. Виняток — випадок, коли ваша політика містить користувача, який автентифікував цей пристрій, у autoApprovers для вузлів виходу. Тоді схвалення відбувається автоматично. Після схвалення, як зазначено в документації Tailscale про вузли виходу, за замовчуванням ним може користуватися будь-який користувач у вашому tailnet без grants або ACL. Це змінюється одразу після налаштування власної політики контролю доступу: відтоді клієнт може використовувати вузол виходу лише за умови, що grant або ACL має autogroup:internet як своє dst. Етап схвалення є навмисним: несхвалена машина не може непомітно стати шляхом виходу для всього вашого tailnet. Тому сприймайте кожен запис autoApprovers як постійно наданий адміністратором дозвіл. Такий самий бар’єр схвалення діє для маршрутів підмереж. Тому машина, яка оголошує приватний діапазон, не працює, доки адміністратор його не прийме. Це перша перешкода під час оголошення приватної мережі для вашого tailnet з VPS.

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

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

Новий 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, якщо адміністратор їх увімкнув, фіксують, які вузли обмінювалися трафіком і коли. Вміст не видно ні ISP, ні Tailscale, але сам факт з’єднання не прихований. Перед вибором інструмента для цього завдання прочитайте чим відрізняються Tor і VPN.
• Від пристрою, який ви вже втратили. Завершення терміну дії ключа є повільним резервним механізмом із типовим періодом 180 days. Швидкий спосіб — видалити пристрій в адміністративній консолі. Заздалегідь з’ясуйте, де розташована відповідна кнопка.

Перевірте власний 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?

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

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

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

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

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

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

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