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), а також відкриті ключі вузлів, до яких йому дозволено підключатися. Тунель і далі є прямим WireGuard-з’єднанням між двома peer, а ваш трафік не проходить через сервер координації. Сервер передає лише метадані: які вузли існують, який ключ належить кожному з них і кому дозволено взаємодіяти з ким.

Це дає три конкретні переваги.

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

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

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

Що вам коштує control plane

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

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

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

Коли достатньо звичайного WireGuard

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

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

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

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

Звичайний WireGuard перестає бути зручним, щойно кожен пристрій має отримати доступ до всіх інших пристроїв. Повна mesh-топологія з N вузлів потребує N помножити на N мінус один peer-блок. Для шести пристроїв це тридцять блоків, які потрібно вручну синхронізувати. Дубльований запис AllowedIPs непомітно перехоплює трафік у 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 оголошує цілу LAN у мережі, тому клієнт не потрібно встановлювати на кожному пристрої:

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 описано схвалення маршруту та параметри forwarding у правильному порядку, щоб уникнути неповністю налаштованого маршруту.

Exit node передає весь traffic клієнта через одну машину. Це повнотунельна поведінка, яку зазвичай мають на увазі під "VPN":

sudo tailscale set --advertise-exit-node

Цей flag — найпростіша частина. У матеріалі перетворення VPS на exit node описано подальші кроки: схвалення маршруту в адміністративній консолі, а потім виправлення поведінки DNS та IPv6, через яку traffic інакше виходитиме неправильним шляхом. Якщо вам потрібно отримати доступ до одного вебсервісу, а не до всієї мережі, 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 network Tailscale. Якщо два вузли не можуть підключитися напряму, потрібно або ввімкнути вбудований relay на власному сервері, або вказати в конфігурації інший. У такому разі relay працює на одному сервері в одному регіоні, а не у глобальній мережі. Вузли на іншому боці планети відчують цю різницю. Якщо ви не хочете самостійно збирати цю частину, self-hosting NetBird — інший спосіб залишити control plane у власній інфраструктурі, оскільки його quickstart запускає management, signal і relay services разом на одному VPS.

Як ухвалити рішення за один прохід

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

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

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

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