Що таке Tailscale і як він працює

Що таке Tailscale?

Tailscale — це VPN, який напряму з’єднує ваші машини між собою замість маршрутизації всього трафіку через один шлюз, яким ви керуєте. На кожному вузлі працює WireGuard, тому пакети передаються між серверами в зашифрованому вигляді, і жоден компонент на шляху не може їх прочитати. Сервер координації, що працює в хмарі, встановлює з’єднання між вузлами. Він зберігає та розповсюджує відкриті ключі й повідомляє кожному вузлу, де розташовані інші вузли. Він також передає правила доступу, які ви налаштували.

Цей поділ є основою всієї архітектури. Площина передавання даних працює за принципом peer-to-peer, а трафік між вузлами шифрується. Площина керування — це сервіс, який Tailscale запускає для вас. Усі важливі питання щодо Tailscale, зокрема незручні питання довіри, випливають із цих двох фактів. Якщо ви вже вручну налаштовували VPN WireGuard на VPS, то Tailscale — це такий самий тунель, але з автоматичним розповсюдженням ключів і обходом мережевих екранів.

Як працює Tailscale?

Ваша приватна мережа вузлів називається tailnet. Коли машина приєднується до неї, відбуваються 4 події.

1. Демон tailscaled запускається, генерує пару ключів WireGuard і зберігає свій стан у /var/lib/tailscale/tailscaled.state. Приватний ключ залишається на цій машині. У документації Tailscale це сформульовано прямо: «приватний ключ ніколи не залишає свій вузол».
2. Вузол входить до coordination server і передає йому свій публічний ключ, а також адреси, за якими, на його думку, до нього можна підключитися. Tailscale описує цей сервер як «спільну скриньку для публічних ключів».
3. Coordination server повертає network map: публічний ключ, адресу tailnet, ім’я машини та можливі кінцеві точки кожного вузла, до якого цьому вузлу дозволено підключатися.
4. Кожна пара вузлів намагається побудувати між собою прямий тунель WireGuard. Якщо це не вдається, пакети передаються через relay.

Кожен вузол отримує стабільну адресу з діапазону 100.64.0.0/10 — діапазону carrier-grade NAT від 100.64.0.0 до 100.127.255.255. Tailscale використовує цей діапазон, оскільки його зарезервовано для інфраструктури провайдерів, тому він рідко конфліктує з приватними адресами, які вже використовують ваші сервери. У Linux тунель відображається як інтерфейс з іменем tailscale0.

Реалізація WireGuard працює всередині tailscaled у userspace, а не в kernel module. Тому Tailscale запускається у container virtualisation, де sudo modprobe wireguard завершується помилкою Operation not supported. Водночас максимальна пропускна здатність на конкретній машині буде нижчою, ніж у kernel WireGuard. Це один із компромісів, розглянутих у матеріалі Tailscale порівняно зі звичайним WireGuard.

Дві команди покажуть поточний стан.

tailscale ip -4
tailscale status

tailscale status виводить по одному рядку для кожного вузла. Важливим є останній стовпець.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct разом з адресою та портом означає, що дві машини знайшли шлях одна до одної, а network traffic передається безпосередньо між вузлами. relay "fra" означає, що traffic проходить через relay Tailscale у Frankfurt. - означає, що активного сеансу з цим вузлом зараз немає. Це нормально.

Що координаційний сервер може і не може бачити

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

Він не має закритого ключа, тому не може розшифрувати трафік між двома вузлами. Шифрування виконується наскрізно між вузлами WireGuard, а координаційний сервер не є вузлом.

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

Як два сервери за різними firewall встановлюють пряме з’єднання

NAT (трансляція мережевих адрес) дає змогу багатьом машинам використовувати одну публічну адресу. Ваш VPS зазвичай має власну публічну адресу, але інші машини, які потрібно підключити до tailnet, часто її не мають: домашній сервер, build runner в офісній мережі або машина за firewall провайдера, який ви не можете налаштувати.

Tailscale знаходить маршрут за допомогою методів, побудованих на стандартах STUN (session traversal utilities for NAT) та ICE. Кожен вузол надсилає невеликий UDP-пакет на STUN-сервер і визначає публічну адресу та порт, які маршрутизатор призначив цьому сокету. Обидва вузли передають ці кандидати на coordination server, який пересилає їх іншій стороні. Потім обидва вузли одночасно починають надсилати пакети один одному. Кожен маршрутизатор спочатку бачить вихідний пакет, тому створює відповідність і приймає відповідь, що надходить із тієї самої адреси. Жодній стороні не потрібне вхідне правило firewall. Саме тому NAS або Pi у домашній мережі може залишатися доступним без налаштованого port forwarding на маршрутизаторі, а використання Tailscale замість port forwarding описує таку конфігурацію, зокрема її обмеження.

Порти мають конкретні значення. Прямі тунелі WireGuard використовують UDP із вихідним портом, значення якого за замовчуванням становить 41641. STUN працює через UDP 3478 із relay servers Tailscale. Для control connection перевага надається звичайному HTTP через TCP 80, обгорнутому у власний зашифрований transport Tailscale; якщо порт 80 не відповідає, використовується HTTPS через TCP 443. Дані, які передаються через DERP servers Tailscale, використовують HTTPS через TCP 443, а peer relay, запущений у власному tailnet, передає їх через UDP. У більшості випадків не потрібно відкривати жодних вхідних портів, але в мережі зі складним NAT дозвіл для вхідного UDP 41641 підвищує ймовірність встановлення прямого з’єднання.

tailscale netcheck

Прочитайте два рядки цього звіту. UDP: true означає, що ця машина може надсилати UDP у мережу Інтернет, а UDP: false — що не може, тому всі з’єднання з цього вузла передаватимуться через relay. MappingVariesByDestIP: true означає, що маршрутизатор призначає різний публічний порт для кожного призначення, тому описане вище передбачення адреси не працює, і такі вузли зазвичай залишаються підключеними через relay.

Коли Tailscale використовує ретранслятор DERP

DERP (designated encrypted relay for packets — призначений зашифрований ретранслятор пакетів) — це резервний варіант. Tailscale запускає ретранслятори в багатьох регіонах, доступні через TCP 443, і вузол, який не може встановити прямий маршрут, передає через один із них свої пакети WireGuard. Винятком є tailnet із призначеними peer-ретрансляторами — власними пристроями, які пересилають трафік через UDP. Tailscale спочатку використовує їх, а до DERP переходить лише тоді, коли жоден із них недоступний, і tailscale status показує таке підключення як peer-relay.

Пакети залишаються зашифрованими. Tailscale прямо зазначає: «сервер DERP ніколи не може розшифрувати ваш трафік. Він лише без аналізу пересилає вже зашифрований трафік від одного вузла до іншого». Ретранслятор бачить шифротекст і бачить, який вузол обмінюється даними з яким.

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

tailscale ping db-1

Перші відповіді надходять через via DERP(fra), а пізніший рядок повідомляє щось на кшталт via 198.51.100.24:41641. Ця зміна означає перехід на прямий тунель. Якщо вона ніколи не відбувається, виконайте tailscale netcheck на обох кінцях. Ретрансльований маршрут також працює. Він збільшує затримку, оскільки кожен пакет проходить через обхідний маршрут і третю машину. Якщо ви помітили повільну передачу даних, а не розірване підключення, у статті чому ретрансльоване підключення Tailscale значно повільніше за пряме вимірюється різниця та показано, як перевести VPS на прямий маршрут.

Підключення VPS до вашого tailnet

Скрипт встановлення підтримує Ubuntu і Debian.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up виводить URL. Відкрийте його, пройдіть автентифікацію, і вузол з’явиться в консолі адміністрування. Потім переконайтеся, що daemon запускається після перезавантаження. Саме цей крок часто пропускають.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled має вивести enabled, а tailscale status — показати новий вузол із його адресою 100.x. Для сервера, створеного скриптом, інтерактивний URL не підходить. Створіть auth key у консолі адміністрування та передайте його разом із тегом, який визначає тип цієї машини.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

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

Для парку серверів важливі два параметри. Типовий строк дії ключів вузлів становить 180 днів (станом на October 2026). Після завершення строку дії ключа «з’єднання до цього endpoint і від нього припинять працювати», доки пристрій повторно не пройде автентифікацію. Адміністратор може вибрати Temporarily extend key на машині зі строком дії ключа, що завершився, у консолі адміністрування. Це дає 30 хвилин, щоб знову ввійти або вимкнути завершення строку дії. Для вузла, автентифікованого за допомогою тега, як у прикладі вище, завершення строку дії ключа типово вимкнено. Для будь-якого іншого сервера без оператора відкрийте рядок машини в консолі адміністрування та виберіть Disable Key Expiry. MagicDNS, увімкнений типово для tailnet, створених 20 October 2022 або пізніше, надає кожному вузлу ім’я, наприклад db-1.yak-bebop.ts.net. Це ім’я розв’язується stub resolver за адресою 100.100.100.100. Використовуйте імена, а не адреси, оскільки після повторного створення вузол отримує нову адресу, але зберігає своє ім’я.

Якщо встановлення завершується помилкою під час роботи apt або репозиторію, у матеріалі розглянуто поширені помилки встановлення Tailscale в Ubuntu та способи їх виправлення.

Доступ до сервісу, прив’язаного до localhost

Саме тут tailnet стає корисним, але водночас у багатьох виникають проблеми. Підключення до tailnet не робить loopback-сервіс доступним з інших вузлів.

ss -tlnp | grep 3000

Якщо команда виводить 127.0.0.1:3000, сокет приймає лише пакети, адресовані на 127.0.0.1. Запит з іншого вузла надходить на адресу 100.x цього вузла, тому ядро не знаходить процесу, який прослуховує цю адресу, і відповідає TCP reset. Клієнт повідомляє Connection refused. Тунель працює. Проблема в listener.

Є два коректні варіанти. Прив’яжіть сервіс до tailnet-адреси вузла. Тоді сервіс не буде доступний через публічний інтерфейс, і proxy не потрібен. Передайте --bind 100.101.102.104 або використайте еквівалентний параметр у конфігурації. Для контейнера опублікуйте порт як -p 100.101.102.104:3000:3000. Або залиште сервіс на loopback і розмістіть Tailscale перед ним.

tailscale serve 3000

Це проксирує запити до http://127.0.0.1:3000 і робить сервіс доступним усередині вашого tailnet за іменем ts.net через HTTPS після ввімкнення HTTPS-сертифікатів для tailnet. Сервіс залишається приватним і доступним лише вашим вузлам. Публічна версія цієї самої схеми називається Funnel. У матеріалі Tailscale serve проти funnel пояснюється, який варіант слід використовувати.

Два пов’язані завдання описано на окремих сторінках. Для доступу до цілої приватної мережі, на якій не встановлено Tailscale, потрібен subnet router на VPS. Щоб спрямувати вихідний інтернет-трафік вузла через інший вузол, потрібен exit node.

Закриття портів, які більше не потрібні

Коли кожен адміністратор отримує доступ до сервера через tailnet, публічний порт 22 більше не потрібен. У цьому полягає практична перевага: закритий порт не можна атакувати перебором, а журнали не заповнюються спробами підключення.

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

sudo ufw allow in on tailscale0
sudo ufw status verbose

Після цього видаліть публічне правило SSH і підключіться повторно, використовуючи ім’я MagicDNS. Зверніть увагу, що насправді робить ufw allow in on tailscale0: він довіряє всьому, що надходить через тунель, тому файл політик Tailscale стає засобом контролю доступу замість ufw. Створюйте політику з урахуванням цього.

Застереження для тих, хто використовує контейнери. Опублікований порт Docker встановлює власні правила NAT і обходить ufw, тому ufw deny його не закриває. У розділі Опубліковані порти Docker в обхід ufw пояснено цей механізм. Публікація порту на адресу tailnet, як описано вище, усуває цю проблему. Якщо застосунок працює через Docker Compose, sidecar Tailscale у стеку Compose дає ще кращий результат і повністю усуває опублікований порт. Тоді контейнер доступний лише за своїм ім’ям у tailnet.

Що Tailscale захищає, а що — ні

Це варто чітко зазначити, оскільки маркетинговий опис розмиває цю межу.

Захищено: трафік між двома вузлами шифрується наскрізним шифруванням за допомогою WireGuard, і жоден relay посередині не може його прочитати. Приватні ключі ніколи не залишають машину, на якій їх було створено. Вузлам не потрібен вхідний публічний порт, тому інтернету нічого сканувати на 22 або 5432. Доступ між вузлами визначається файлом політики, а не тим, хто знає адресу.

Не захищено: coordination server бачить граф ваших пристроїв. Самі ці метадані є чутливими, оскільки назви машин, власники, адреси та час перебування онлайн описують вашу інфраструктуру. Сервер також розповсюджує ключі, і саме це створює серйозніший ризик. Tailscale прямо зазначає: "If Tailscale were malicious, and stealthily inserted new nodes into your network, then Tailscale could send or receive traffic to your existing nodes in plaintext." Ваш single sign-on provider входить до того самого ланцюжка довіри, оскільки той, хто може створити там identity, може додати вузол. Скомпрометований вузол також є peer усередині tailnet, тому він може отримати доступ до всього, що дозволяє ваша політика. Чи є такий ризик прийнятним, залежить від того, від кого ви захищаєтеся. Повна модель довіри розглядає кожен із цих випадків, зокрема те, що саме може зробити зловмисник із викраденим identity account.

Є два способи зменшити ризик, пов’язаний із розповсюдженням ключів. Перший — tailnet lock. Він вимагає, щоб наявні довірені вузли криптографічно підписали новий вузол, перш ніж інші вузли його приймуть. Control plane, який додає вузол без дійсного підпису, ігнорується. Admin console генерує точний рядок tailscale lock init для вузлів, що виконують підписання, а кожен вузол може перевірити отриману інформацію.

tailscale lock status

Усі вузли мають повідомляти однаковий набір довірених ключів підпису. Другий спосіб — самостійно запускати control plane. Self-hosted Headscale coordination server використовує той самий протокол і працює з тими самими клієнтами. Це переносить граф пристроїв і розповсюдження ключів на обладнання, яким володієте ви. Водночас ви відповідаєте за доступність цього сервера. Якщо ви все ще порівнюєте self-hosted control planes і не зупинилися на цьому варіанті, NetBird — це окрема mesh VPN, сервер якої ви повністю запускаєте на одному VPS.

Є одне налаштування, яке потрібно виправити в перший день. Новий tailnet за замовчуванням працює в дозвільному режимі: "the default tailnet policy file enables communication between all devices within the tailnet." Щойно ви додаєте секцію acls, модель змінюється на заборону за замовчуванням, і проходять лише ваші правила.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

Ця політика дозволяє учасникам tailnet підключатися через SSH до серверів із відповідними тегами й не дає їм іншого доступу. Додавайте окреме правило для кожного сервісу, а не залишайте wildcard, оскільки wildcard дає змогу одному викраденому ключу ноутбука отримати доступ до вашої бази даних.

Режими відмов і повідомлення, які ви побачите

tailscale status завжди повідомляє relay. Вузли не змогли встановити прямий шлях. Виконайте tailscale netcheck на обох кінцях. UDP: false означає, що вихідний UDP-трафік заблоковано, тому працювати може лише relay. MappingVariesByDestIP: true означає, що з’єднанню заважає жорсткий NAT. Увімкнення вхідного UDP 41641 на стороні, якою ви керуєте, часто усуває проблему.

Вузол, який працював кілька місяців, зник. Поширена причина — термін дії ключа вузла завершився після стандартних 180 днів. Спочатку перевірте машину в адміністративній консолі. Якщо ключ має статус expired, команда sudo tailscale up на цьому сервері відновить вузол. Вимкнення завершення терміну дії ключів на серверах запобігає повторенню проблеми. Якщо термін дії не завершився, перевірте файл політики, оскільки Tailscale радить для пристрою, відсутнього в tailscale status, перевірити правила доступу, які можуть блокувати з’єднання.

Піри відображаються, але час очікування з’єднання минає. Якщо tailscale ping отримує відповіді, зв’язність працює, імовірна причина — політика забороняє цей трафік. Перевірте розділ acls на наявність правила для цього джерела, призначення та порту. Заборонений пакет відкидається, а не отримує відповідь, тому ви бачите повідомлення про завершення часу очікування, а не Connection refused.

Імена MagicDNS не розпізнаються. ping db-1 завершується помилкою, тоді як ping 100.101.102.104 працює. Спочатку переконайтеся, що клієнт приймає DNS-налаштування Tailscale: вузол, запущений із --accept-dns=false, не надсилає запити до stub resolver за адресою 100.100.100.100. Потім перевірте cat /etc/resolv.conf та всі інші компоненти, які записують цей файл. У системі з systemd-resolved цей файл зазвичай є символічним посиланням на /run/systemd/resolve/stub-resolv.conf, тому відсутність у ньому 100.100.100.100 є нормальною. Якщо tailscaled безпосередньо записує файл, DHCP-клієнт або інший інструмент, який перезаписує його, порушує роботу MagicDNS. Якщо жодна з цих причин не підходить, проблема також може бути в локальній або мережевій DNS-конфігурації. Це той самий клас проблем, що й порушення роботи DNS усередині тунелю WireGuard.

tailscale up відхиляє ваш тег. Тег не оголошено в розділі tagOwners файлу політики. Додайте його туди, а потім повторно виконайте команду.

FAQ

Чи є Tailscale VPN або mesh-мережею?

Обидва терміни правильні, але вони описують різні рівні. Тунелі працюють на WireGuard, тому це VPN. Топологія є mesh-мережею, оскільки кожен вузол напряму встановлює тунель з кожним вузлом, з яким обмінюється трафіком, замість передавання кожного пакета через один центральний сервер. Сервер координації належить до площини керування, а не до площини передавання даних. Тому, якщо він стане недоступним, наявні тунелі продовжать передавати трафік. Під час збою припиняється підключення нових вузлів і застосування змін ключів або політик. За замовчуванням це не privacy VPN: вебсайти й далі бачать вашу власну публічну адресу, доки ви не спрямували трафік через exit node, а що саме Tailscale приховує від вебсайтів і вашого ISP залежить від конкретної конфігурації.

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

Вміст трафіку — ні. Трафік шифрується end-to-end між вузлами за допомогою WireGuard, приватні ключі ніколи не залишають вузли, а relay DERP пересилає пакети, які не може розшифрувати. Водночас Tailscale бачить метадані: імена машин, власників, публічні ключі, адреси endpoint і час перебування кожного вузла в мережі. Tailscale також поширює ключі, тому скомпрометований сервер координації може спробувати додати вузол, якому ваша інфраструктура потім довірятиме. Tailnet lock блокує таку атаку, вимагаючи підписи від ваших власних довірених вузлів, а Headscale усуває hosted control plane з цієї схеми.

Чи потрібно відкривати порти firewall для Tailscale?

Для вхідних підключень — майже ніколи. Власна документація Tailscale зазначає: "most of the time, you don't need to open any firewall ports." Для вихідних підключень вузлу потрібен TCP 443 до сервера координації та relay, а також UDP 3478 для STUN. Прямі тунелі використовують UDP із вихідним портом, значення якого за замовчуванням становить 41641. Дозволити вхідний UDP 41641 необов’язково. Це лише допомагає прямим підключенням встановлюватися в мережах зі складними обмеженнями.

Чому інші вузли не можуть підключитися до мого сервісу через порт 3000?

Спочатку перевірте адресу прив’язки за допомогою ss -tlnp. Listener на 127.0.0.1:3000 відхиляє підключення, що надходять на адресу вузла 100.x у tailnet, оскільки цей socket приймає лише loopback destination, а клієнт отримує Connection refused. Прив’яжіть сервіс до адреси tailnet або запустіть tailscale serve 3000, щоб проксувати підключення. Якщо listener уже працює на 0.0.0.0, а підключення завершується тайм-аутом, а не відмовою, адреса прив’язки не є причиною. Спочатку перевірте правила policy та host firewall, потім network firewall і те, чи не завершився строк дії автентифікації на одному з пристроїв.

Чи варто запускати Headscale замість сервера координації Tailscale?

Запускайте Headscale, якщо граф пристроїв або розповсюдження ключів мають залишатися на інфраструктурі під вашим контролем, або якщо tailnet має працювати без залежності від зовнішнього сервісу. Клієнти та протокол залишаються тими самими. Недолік полягає в тому, що тепер ви самостійно обслуговуєте сервер координації. Якщо він стане недоступним, нові вузли не зможуть приєднатися, а зміни політик не застосовуватимуться. Для невеликої інфраструктури hosted control plane з увімкненим tailnet lock зазвичай є кращим компромісом.