WireGuard, Tailscale чи Headscale: що обрати для VPS

WireGuard і Tailscale: коротка відповідь

WireGuard і Tailscale — це не вибір між двома протоколами, оскільки Tailscale працює поверх WireGuard. Tailscale використовує те саме шифрування й той самий тунель, а потім додає control plane: сервер координації, який обмінюється публічними ключами, призначає адреси, пробиває отвори через NAT (network address translation) і застосовує політику доступу. Ви обираєте, яку частину цієї координації хочете виконувати самостійно.

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

Що насправді дає control plane

У стандартному WireGuard немає механізму виявлення вузлів. Кожен peer — це текстовий блок, який ви створюєте вручну: відкритий ключ, рядок AllowedIPs і Endpoint, якщо цей peer доступний. Щоб додати одну машину до мережі з десяти машин, потрібно відредагувати десять конфігураційних файлів, оскільки кожна сторона має знати ключ іншої. Тому майже кожне self-hosted розгортання WireGuard використовує топологію hub-and-spoke: один сервер із публічною IP-адресою та клієнти, які взаємодіють лише з ним.

Control plane усуває потребу в ручному редагуванні. Кожен вузол реєструється один раз, отримує адресу з діапазону 100.64.0.0/10 CGNAT (carrier grade NAT), а також відкриті ключі вузлів, до яких йому дозволено підключатися. Тунель між двома peer і далі є прямим з’єднанням WireGuard, а ваш трафік не проходить через сервер координації. Сервер передає лише метадані: які вузли існують, якому вузлу належить кожен ключ і яким вузлам дозволено взаємодіяти між собою.

Це дає три практичні можливості.

Проходження через NAT. Два ноутбуки за двома домашніми маршрутизаторами не мають спільної публічної IP-адреси. Tailscale використовує STUN (session traversal utilities for NAT), щоб визначити зовнішню адресу та порт кожної сторони. Потім обидві сторони одночасно надсилають пакети, тому кожен маршрутизатор спочатку бачить вихідний потік і приймає відповідь. Якщо це не спрацьовує, трафік переходить на DERP relay — зашифрований ретранслятор, яким керує Tailscale. Дані залишаються зашифрованими від кінця до кінця під час проходження через relay, оскільки relay не має ключів. Виконайте tailscale status, і в рядку кожного peer буде зазначено direct або relay. Виконайте tailscale netcheck, щоб перевірити, який relay є найближчим і чи дозволяє ваша мережа UDP взагалі.

Ротація ключів із терміном дії. Ключі WireGuard не мають терміну дії. Ключ, створений три роки тому, працюватиме безстроково, якщо вручну не видалити блок peer. Натомість Tailscale встановлює термін дії ключів вузлів. Станом на October 2026 стандартний термін дії для нового tailnet становить 180 days. Машина, яка не пройшла повторну автентифікацію, припиняє підключатися. Для окремого пристрою можна вимкнути завершення дії ключа, наприклад для сервера або subnet router, на якому ніхто не виконуватиме вхід.

Політики замість маршрутизації. У стандартному WireGuard AllowedIPs одночасно є таблицею маршрутизації та списком контролю доступу, тому правило «alice може отримувати доступ до бази даних» потрібно виразити через діапазон IP-адрес. Tailscale зберігає окремий файл політик, у якому правила визначають користувачів, групи й теги. Правило може дозволити tag:laptop доступ до tag:db через порт 5432 і заборонити будь-який інший доступ. Це правило зберігається навіть після того, як машина отримує нову адресу.

Вартість control plane для вас

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

Є й друга вартість, яку легко не помітити. Tailscale працює як daemon на кожній машині, тому його потрібно регулярно оновлювати на кожній машині. Звичайний WireGuard в Ubuntu 24.04 — це kernel module, який постачається разом із дистрибутивом і оновлюється разом із kernel.

Третя стаття витрат — billing. Станом на October 2026 план Personal безкоштовний і підтримує необмежену кількість пристроїв користувачів для 6 користувачів, Standard коштує $8 за користувача на місяць, а Premium — $18 за користувача на місяць. Для домашньої мережі сервіс залишається безкоштовним. Для команди з 10 осіб — ні. Перехід за цей ліміт здебільшого залежить від кількості користувачів, а не пристроїв, за одним винятком: сервери та інші tagged devices мають окремий ліміт. Кожен план включає 50 tagged resources, а станом на October 2026 на сторінці з цінами вказано $1 на місяць за кожен ресурс понад цей ліміт. Перед тим як запросити сьомого користувача або додати тег до п’ятдесят першого сервера, варто прочитати що насправді охоплює безкоштовний план.

Коли правильним вибором є звичайний WireGuard

Обирайте звичайний WireGuard, якщо топологія справді має схему hub-and-spoke. Один VPS із публічною IP-адресою, три або чотири пристрої, які підключаються до нього, і відсутність потреби забезпечувати зв’язок між цими пристроями. Конфігурація вміщується на одному екрані, немає daemon, який потрібно оновлювати, немає облікового запису, який можна втратити, і жоден зовнішній сервіс не стоїть між вами та сервером.

Це також правильний вибір, якщо ви хочете зрозуміти рівень, на якому побудовано все інше. У матеріалі Самостійне розгортання WireGuard VPN на VPS описано генерацію ключів, wg0.conf, IP forwarding, NAT і помилки handshake. Ключі та handshake досі працюють під кожним tailnet, а IP forwarding знову стає потрібним, щойно вузол tailnet починає працювати як subnet router або exit node. Якщо ви все ще розглядаєте старіший варіант, у матеріалі WireGuard проти OpenVPN розглянуто чотири випадки, у яких OpenVPN зберігає перевагу.

Установлення коротке:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

Звичайний WireGuard перестає бути зручним, щойно кожен пристрій має отримувати доступ до всіх інших пристроїв. Повна mesh-топологія з N вузлів потребує N помножити на N мінус один peer-блок. Для шести пристроїв це тридцять блоків, які потрібно вручну підтримувати синхронізованими, а дубльований запис AllowedIPs непомітно перехоплює traffic у peer, який отримав його першим, без будь-якого повідомлення про помилку.

Коли Tailscale є правильним вибором

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

Встановити клієнт можна однією командою з офіційного інсталятора:

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

tailscale up виводить URL. Відкрийте його, увійдіть у систему, і пристрій буде додано до мережі. Немає потреби копіювати ключ або відкривати вхідний порт, оскільки daemon встановлює вихідне з’єднання із сервером координації та підтримує його відкритим. Тому вузол Tailscale працює навіть у мережі, де ви взагалі не керуєте firewall.

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

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

Маршрут залишається неактивним, доки ви не схвалите його в адміністративній консолі. Це зроблено навмисно: вузол не може самостійно додати маршрут у вашу мережу. Клієнтам Linux також потрібен sudo tailscale set --accept-routes, оскільки Linux за замовчуванням не приймає оголошені маршрути. Тому маршрут, який на стороні сервера виглядає схваленим, усе одно не працюватиме на ноутбуці з Linux, доки ви не встановите це значення. Якщо вам потрібна саме така схема, у матеріалі налаштування subnet router на VPS описано крок схвалення та параметри пересилання в порядку, який дає змогу уникнути неповністю налаштованого маршруту.

Exit node передає звичайний інтернет-трафік клієнта через один пристрій. Йдеться про весь трафік, який уже не спрямований до іншого пристрою tailnet або через схвалений маршрут підмережі. Це повнотунельний режим, який зазвичай мають на увазі під «VPN». У Linux перед його оголошенням потрібні ті самі параметри IP forwarding, що наведені вище:

sudo tailscale set --advertise-exit-node

Цей прапорець є найпростішою частиною налаштування. У матеріалі перетворення VPS на exit node описано подальші кроки: схвалення маршруту в адміністративній консолі та виправлення поведінки DNS і IPv6, через яку трафік інакше може виходити неправильним шляхом. Якщо потрібно отримати доступ лише до одного вебсервісу, а не до всієї мережі, матеріал serve і funnel описує спосіб розмістити HTTPS перед одним локальним портом — лише для tailnet або з відкритим доступом з публічного інтернету.

Коли Headscale є правильним вибором

Headscale — це реалізація coordination server із відкритим вихідним кодом, яка працює на VPS, що належить вам. Офіційні клієнти Tailscale підключаються до нього замість hosted service:

sudo tailscale up --login-server https://headscale.example.com

У data path нічого не змінюється. Це все ще WireGuard, і з’єднання між вузлами все ще встановлюються напряму, якщо це дозволяє мережа. Змінюється лише те, що список вузлів, ключі та політики зберігаються у файлі SQLite на диску, який належить вам. Ніхто ззовні не бачить структуру вашої мережі, не може вимкнути ваш обліковий запис або стягувати плату за кожного користувача.

Це вимагає реальної роботи. Тепер ви запускаєте публічний HTTPS-сервіс, а отже, потрібні DNS-ім’я, сертифікат і reverse proxy, який коректно передає WebSocket upgrades. Ви відповідаєте за його доступність. Якщо coordination server недоступний, нові вузли не можуть зареєструватися, а наявні вузли не можуть дізнатися про зміни. Headscale також ще не досяг версії 1.0, а в minor releases були breaking changes, тому перед кожним оновленням читайте changelog. У статті Запуск Headscale як власного control server для Tailscale описано встановлення, config.yaml, preauth keys і порти, які потрібно відкрити.

Одна особливість часто стає очевидною лише згодом. Headscale не має глобальної relay-мережі Tailscale. Якщо два вузли не можуть встановити пряме з’єднання, потрібно або ввімкнути вбудований relay на власному сервері, або вказати в конфігурації інший relay. Такий relay працює на одному сервері в одному регіоні, а не у глобальній мережі. Вузли на іншому боці планети відчувають цю різницю.

Якщо ви не хочете налаштовувати цю частину самостійно, self-hosting NetBird — це інший спосіб залишити control plane у власній інфраструктурі. Його quickstart одночасно запускає management, signal і relay-сервіси на одному VPS. Однак NetBird не є готовою заміною сервера Tailscale, як Headscale: він постачається з власними клієнтами та власною моделлю політик. Тому перед вибором NetBird замість Headscale ознайомтеся з матеріалом про відмінності NetBird і Tailscale у правилах доступу та relay-сервісах.

Як визначити вибір за один прохід

З’ясуйте, скільки машин мають з’єднуватися між собою. Якщо всі вони лише обмінюються даними із сервером, звичайний WireGuard потребує менше програмного забезпечення та дає той самий результат.

З’ясуйте, чи мають машини стабільні публічні адреси. Якщо більшість із них працює за NAT, яким ви не керуєте, вам потрібна площина керування, оскільки встановлення з’єднання через NAT є складною частиною, яку не варто реалізовувати самостійно.

З’ясуйте, кому дозволено знати структуру вашої мережі. Якщо сторонні компанії не повинні мати до неї доступу або кількість користувачів робить оплату за кожне робоче місце невигідною, запустіть Headscale і врахуйте, що відтепер вам доведеться адмініструвати сервер керування. Якщо саме оплата спонукає до змін, виконайте розрахунки до початку міграції, оскільки фактична вартість для команди вашого розміру здебільшого залежить від кількості користувачів з обліковими записами, а не від кількості машин, які ви запускаєте, доки кількість ваших tagged серверів не перевищить 50, що входять до кожного плану. Ці два показники рідко збігаються.

Ви можете без великих витрат змінити рішення. Оскільки в усіх трьох варіантах використовується той самий протокол площини даних, перехід зі звичайного WireGuard на скоординовану mesh-мережу потребує встановлення клієнта, а не повної перебудови. Перехід із Tailscale на Headscale полягає в повторній реєстрації кожного вузла на іншому сервері автентифікації.

Що жоден із трьох варіантів не дає

Жоден із них не є firewall. Тунель визначає, які пакети передаються, а не які сервіси приймають з’єднання. Сервер, доступний через тунель, усе одно доступний з інтернету через кожен порт, який ви залишили відкритим. Тому правила UFW firewall на VPS мають і надалі виконувати свою роботу. Файл політик Tailscale обмежує доступ інших вузлів і не впливає на публічний інтерфейс.

Жоден із них не забезпечує автентифікацію для окремих сервісів і не створює audit trail дій користувача після підключення. Розглядайте всі три варіанти як транспорт, а перевірку входу реалізуйте в застосунку.

FAQ

Чи є Tailscale просто WireGuard із додатковими кроками?

Tailscale використовує протокол WireGuard для передавання даних, тому шифрування та тунель однакові. Додатково він забезпечує координацію: обмін ключами, призначення адрес, проходження NAT за допомогою STUN і ретрансляторів DERP, завершення строку дії ключів і файл політик, у якому вказуються користувачі, а не діапазони IP-адрес. У звичайному WireGuard ці завдання ви виконуєте самостійно. Вони стають складними, коли комп’ютери переходять між різними мережами.

Чи проходить мій трафік через сервери Tailscale?

Зазвичай ні. Після того як сервер координації познайомить вузли, вони підключаються безпосередньо один до одного, а tailscale status показує direct у рядках із цими вузлами. Якщо прямий шлях встановити неможливо, трафік переходить на ретранслятор DERP, і в рядку відображається relay. Навіть у цьому разі ретранслятор передає зашифровані пакети й не має ваших приватних ключів WireGuard, тому не може прочитати їхній вміст. Виконайте tailscale netcheck, щоб перевірити, чи не блокує ваша мережа UDP, потрібний для прямих підключень.

Чи можна використовувати Headscale з офіційними застосунками Tailscale?

Так. Headscale використовує той самий протокол керування, тому офіційні клієнти підключаються за допомогою sudo tailscale up --login-server https://headscale.example.com. У настільних і мобільних застосунках також можна вказати власний сервер входу, але на кожній платформі це налаштування розташоване в іншому місці. Мобільним застосункам найчастіше потрібна певна версія. Перед міграцією всієї мережі перевірте один телефон.

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

Клієнту Tailscale не потрібен вхідний порт, оскільки він сам встановлює вихідне підключення до сервера координації та підтримує його відкритим. Для self-hosted сервера Headscale потрібні вхідні порти: 443 для протоколу керування, 80, якщо використовується перевірка сертифіката HTTP-01, і лише 3478/udp, якщо ввімкнено вбудований ретранслятор. Для звичайного WireGuard його UDP-порт прослуховування, зазвичай 51820, має бути відкритим на сервері та в окремому мережевому firewall, який використовує ваш провайдер.

Який із трьох варіантів найшвидший?

Пропускна здатність однакова, оскільки всі три варіанти передають пакети за допомогою WireGuard. Відмінність проявляється під час встановлення з’єднання та залежить від якості шляху. Звичайний WireGuard із правильним Endpoint щоразу підключається безпосередньо. Tailscale і Headscale більшість часу підключаються безпосередньо, але переходять на ретранслятор, коли мережа блокує hole punching, а ретранслятор збільшує затримку. Перевірте власний шлях за допомогою tailscale ping <node>, який показує, чи є маршрут прямим або проходить через ретранслятор, або за допомогою iperf3 через тунель. Якщо на прямому шляху це значення набагато нижче за швидкість вашого каналу, проблема не у виборі між цими трьома варіантами. Звичайною причиною є невідповідність path MTU, яка проявляється однаково незалежно від наявності control plane.