Headscale self-hosted на VPS: свой control server для Tailscale-сети

Headscale на VPS нужен тем, кто хочет использовать Tailscale-подобную mesh-сеть, но держать control server под своим управлением. Это сценарий для self-hosted инфраструктуры: домашняя лаборатория, личные серверы, небольшая команда, несколько VPS, офисные машины, ноутбуки, NAS, роутеры и exit node, которые нужно связать в одну приватную сеть.

Главная боль пользователя здесь — свой control server. Человек уже понимает удобство Tailscale, но не хочет полностью зависеть от hosted control plane, хочет контролировать регистрацию устройств, политики доступа, ключи, routes, DNS-настройки и жизненный цикл своей tailnet-сети.

Но важно не путать Headscale с обычным VPN-сервером. Headscale не заменяет WireGuard-сервер в классическом смысле и не является “панелью для продажи VPN”. Это self-hosted control plane для Tailscale-клиентов. Он помогает устройствам находить друг друга, управляет регистрацией, пользователями, ACL и маршрутами, но сам по себе не делает VPS магическим VPN для всех сценариев.

Что такое Headscale простыми словами

Headscale — это open-source реализация control server для Tailscale. В обычной схеме Tailscale-клиенты подключаются к control plane Tailscale. В Headscale-схеме control plane работает на вашем VPS, а клиенты на Linux, Windows, macOS, iOS и Android подключаются к вашему серверу как к custom control server.

Control server нужен не для постоянной передачи всего трафика. Его задача — регистрация устройств, выдача конфигурации, координация peers, управление маршрутами, пользователями, ключами и сетевой политикой. Когда устройства могут соединиться напрямую, трафик идет между ними напрямую. Если прямое соединение невозможно, может использоваться relay через DERP.

То есть Headscale — это не “поставил сервер и весь трафик пошел через VPS”. Для единого выхода в интернет нужен exit node. Для доступа к подсети нужен subnet router. Для DNS-политики нужен MagicDNS или отдельный resolver. Headscale управляет этой сетью, но каждый сценарий нужно включать отдельно.

Кому подходит Headscale на VPS

Headscale имеет смысл, если вам нужен контроль над собственной приватной mesh-сетью, а не просто кнопка “подключиться к VPN”.

У вас есть несколько VPS, домашних серверов, ноутбуков и рабочих машин.
Вы хотите self-hosted control server вместо hosted control plane.
Нужно управлять устройствами в одной приватной tailnet-сети.
Нужны ACL, users, pre-auth keys, routes и управляемая регистрация устройств.
Нужно подключать Linux-серверы, macOS, Windows, iOS и Android-клиенты.
Нужно построить личную или командную mesh-сеть без ручной выдачи WireGuard-конфигов.
Вы хотите поднять exit node или subnet router, но управлять этим через свой control server.
Вам важен контроль над инфраструктурой и вы готовы обслуживать VPS.

Headscale не нужен, если вам достаточно обычного Tailscale-аккаунта, нет требований к self-hosted control plane и вы не хотите обслуживать сервер. Для многих пользователей hosted Tailscale проще, надежнее и быстрее. Headscale стоит выбирать не из-за моды, а из-за конкретной потребности в контроле.

Кому Headscale не подходит

Headscale — плохой выбор, если вы хотите полностью готовый VPN без администрирования. Это self-hosted infrastructure, а не SaaS-кнопка.

Вы не хотите обслуживать VPS.
Вы не хотите разбираться с reverse proxy, TLS и обновлениями.
Вам нужен публичный VPN-сервис для клиентов.
Вам нужна массовая продажа доступов, биллинг и автоматическая выдача конфигов.
Вам нужна enterprise-поддержка и гарантии hosted-сервиса.
Вы хотите подключить пользователей без понимания client setup.
Вы ожидаете, что Headscale сам решит routing, DNS, exit node и DERP без настройки.

Если нужен обычный личный VPN, проще начать с WireGuard, Amnezia-like setup или Tailscale exit node. Если нужен именно self-hosted control server для Tailscale-клиентов, тогда Headscale — правильная тема.

Почему Headscale лучше ставить на VPS

Control server должен быть доступен устройствам из интернета. Поэтому VPS подходит лучше домашнего сервера: у него есть публичный IP, стабильное подключение, нормальный uptime и возможность выбрать локацию.

Преимущества VPS для Headscale:

публичный IPv4;
стабильная доступность 24/7;
нормальная точка для TLS и reverse proxy;
не нужен белый IP дома;
удобно подключать мобильные устройства и удаленные серверы;
можно быстро переустановить ОС;
проще держать отдельную инфраструктурную роль;
можно добавить DERP, exit node или DNS-сервисы при необходимости.

Домашний сервер под Headscale возможен, но он хуже для внешней доступности: динамический IP, CGNAT, домашний роутер, перебои электричества, проблемы с портами и сертификатами. Для control server, от которого зависит вся mesh-сеть, VPS обычно практичнее.

Какая конфигурация VPS нужна для Headscale

Headscale сам по себе не требует мощного сервера. Это control plane, а не медиасервер и не proxy для всего трафика. Но VPS должен быть стабильным, с нормальным диском, публичным IP и достаточным запасом для reverse proxy, логов, базы данных и возможных дополнительных сервисов.

Минимальный вариант для личной сети:

1 vCPU;
1 GB RAM;
10-20 GB SSD/NVMe;
1 публичный IPv4;
Ubuntu 22.04/24.04 или Debian 12;
доступ по SSH;
домен или поддомен для Headscale;
TLS-сертификат через reverse proxy.

Комфортный вариант для семьи, лаборатории или небольшой команды:

2 vCPU;
2 GB RAM;
20-40 GB SSD/NVMe;
1 публичный IPv4;
стабильная локация рядом с основными администраторами;
backup или snapshot;
мониторинг доступности;
отдельный домен для control server.

Если на том же VPS будут работать reverse proxy, Headscale UI, DERP, AdGuard Home, Unbound, monitoring или exit node, лучше брать запас по RAM. Headscale легкий, но проблема обычно не в нем, а в том, что на один маленький VPS ставят все подряд.

Что нужно подготовить перед установкой

Перед установкой Headscale не начинайте с копирования команд из случайного гайда. Сначала подготовьте архитектуру.

VPS с чистой Ubuntu или Debian.
Домен или поддомен, например hs.example.com.
DNS A-запись на IP VPS.
Reverse proxy: nginx, Caddy или Traefik.
TLS-сертификат.
Решение по базе данных: SQLite для простого старта или PostgreSQL для более сложной эксплуатации.
Решение по users/namespaces.
Понимание, какие устройства будут подключаться.
Понимание, нужны ли ACL, MagicDNS, routes, exit node и DERP.
План backup для конфигов и базы.

Самая частая ошибка — установить Headscale, подключить пару устройств, а потом понять, что домен, TLS, users, ACL и backup не продуманы. Переделывать control server после подключения устройств неприятнее, чем сразу сделать аккуратно.

Headscale через reverse proxy

Headscale обычно ставят за reverse proxy. Это удобно, если на VPS уже есть nginx, Caddy или Traefik, а также если нужно нормально управлять TLS-сертификатами и HTTPS-доступом.

Правильная внешняя схема:

публичный DNS указывает на VPS;
порт 443 принимает reverse proxy;
reverse proxy проксирует запросы к Headscale на локальный порт;
Headscale не торчит напрямую наружу на случайном порту;
TLS терминируется на reverse proxy или настроен корректно по выбранной схеме;
административные endpoints и UI закрыты сильной авторизацией или ограничением доступа.

Для новичка Caddy часто проще, потому что он умеет автоматически получать TLS-сертификаты. Nginx привычнее для администраторов и гибче в уже существующей инфраструктуре. Traefik удобен в Docker-среде, если все сервисы живут в compose/labels.

SQLite или PostgreSQL для Headscale

Для личной сети и простого VPS чаще всего достаточно SQLite. Это проще, меньше движущихся частей, легче backup и меньше риска сломать все из-за отдельной базы данных.

PostgreSQL имеет смысл, если у вас более серьезная эксплуатация, привычный database stack, внешние backup-процедуры, несколько администраторов или требования к операционной дисциплине. Но PostgreSQL добавляет сложность: отдельный сервис, права, backup, обновления, миграции, мониторинг.

Практичный выбор такой:

личная сеть, homelab, несколько устройств — SQLite;
небольшая команда с аккуратным обслуживанием — SQLite или PostgreSQL по опыту администратора;
сложная инфраструктура с уже существующим PostgreSQL-стеком — PostgreSQL;
новичок без опыта баз данных — SQLite.

Не выбирайте PostgreSQL только потому, что он “серьезнее”. Серьезнее не значит проще. Для Headscale на небольшом VPS простота часто надежнее.

Установка Headscale: пакет, binary или Docker

Есть несколько способов установки. Лучший зависит от того, как вы обслуживаете сервер.

Пакет для Debian/Ubuntu удобен тем, что проще интегрируется с systemd и привычной системой обновлений. Standalone binary дает больше ручного контроля, но требует больше дисциплины. Docker удобен, если весь сервер уже ведется через Docker Compose.

Практический выбор:

обычный VPS без Docker-инфраструктуры — ставьте через официальный пакет;
опытный администратор и нужна точная версия — можно использовать binary;
все сервисы уже в Docker Compose — можно ставить Headscale в Docker;
новичок без понимания volume, network и reverse proxy в Docker — не начинайте с compose-хаоса.

Главное — не смешивать стили без причины. Если на сервере все через systemd, Headscale через пакет будет проще. Если весь стек через Docker Compose, делайте compose аккуратно с volume для данных и конфигов.

Как работает подключение клиентов к Headscale

Клиент Tailscale должен использовать custom control server URL. Это главное отличие от обычного входа в Tailscale. На Linux это обычно делается через CLI, на других системах — через настройки клиента, профиль, MDM или специальные параметры, которые зависят от платформы и версии клиента.

Общая логика подключения:

установить Tailscale client на устройство;
указать URL вашего Headscale control server;
получить registration URL или использовать pre-auth key;
зарегистрировать устройство в Headscale;
проверить, что устройство появилось в списке nodes;
проверить связность между устройствами;
назначить routes, exit node или ACL, если они нужны.

Не рассчитывайте, что все клиенты на всех платформах ведут себя одинаково. Linux обычно проще диагностировать через CLI. Windows, macOS, iOS и Android могут иметь свои особенности custom control server. Перед массовым внедрением проверьте каждую платформу на одном тестовом устройстве.

Users, namespaces и организация устройств

В Headscale важно аккуратно организовать пользователей и устройства. Если все подключать в одну кучу без именования, через месяц будет непонятно, чей ноутбук, какой сервер является exit node и какой node уже старый.

Хорошая практика:

создавать понятные users/namespaces;
давать устройствам нормальные имена;
разделять личные, серверные и командные nodes;
удалять старые устройства;
не оставлять одноразовые тестовые nodes;
использовать pre-auth keys аккуратно;
не хранить ключи в открытых чатах;
документировать, какие subnet routes и exit nodes включены.

Имена вроде test, server, iphone, linux быстро превращаются в мусор. Лучше использовать понятные названия: dad-iphone, office-router, nl-vps-exit, home-nas, work-macbook.

ACL в Headscale

ACL нужны, чтобы не все устройства видели все. Без политики доступа mesh-сеть быстро становится слишком открытой: любой подключенный node потенциально может обращаться к сервисам, которые ему не нужны.

ACL стоит использовать, если:

есть несколько пользователей;
есть серверы и личные устройства в одной сети;
есть рабочие и домашние nodes;
есть subnet routes;
есть exit nodes;
нужно ограничить доступ к admin-сервисам;
нужно разделить команду и личную инфраструктуру.

Для личной сети можно начать с простой политики, но не оставляйте полный доступ навсегда, если сеть растет. Чем больше устройств, тем важнее ACL.

MagicDNS и DNS в Headscale

MagicDNS удобен тем, что устройства можно открывать по именам, а не только по IP. Например, вместо запоминания Tailscale IP можно обращаться к серверу по понятному имени.

Но DNS в self-hosted mesh-сети нужно проектировать аккуратно. Возможные схемы:

использовать MagicDNS только для tailnet-имен;
использовать системный DNS клиентов;
добавить private DNS resolver на VPS;
использовать AdGuard Home или Unbound отдельно;
разделить DNS для tailnet и обычного интернета.

Не пытайтесь одновременно включить MagicDNS, AdGuard Home, Unbound, split DNS, exit node и custom resolver без понимания. Если после этого “интернет не работает”, диагностика станет неприятной. Начните с простой схемы, затем добавляйте DNS-слои постепенно.

Exit node в сети Headscale

Exit node нужен, если вы хотите направить интернет-трафик клиентского устройства через конкретный node. Например, VPS в Нидерландах становится единым выходом в интернет для ноутбука и телефона.

Headscale может управлять nodes, которые advertise exit node, но сам exit node нужно настраивать на соответствующем устройстве. На Linux-сервере обычно требуется включить IP forwarding и корректно настроить клиент.

Типовые ошибки exit node:

node рекламирует exit route, но не включен forwarding;
клиент не выбрал exit node;
routes не одобрены;
DNS уходит не туда;
firewall блокирует трафик;
VPS выбран в плохой локации;
ожидали, что Headscale сам сделает весь routing.

Если вам нужен именно единый выходной IP, планируйте exit node отдельно. Headscale — control server, а не автоматическая замена всем сетевым настройкам.

Subnet router в Headscale

Subnet router нужен, если вы хотите дать доступ к сети за конкретным node. Например, у вас дома есть сервер в сети 192.168.1.0/24, а вы хотите обращаться к нему через tailnet.

Это другой сценарий, не exit node. Exit node отправляет весь интернет-трафик через выбранный узел. Subnet router дает доступ к конкретной подсети за узлом.

Для subnet router важно:

advertise нужную route;
одобрить route на стороне Headscale;
настроить forwarding на узле;
проверить обратные маршруты;
не открыть лишние подсети всем пользователям;
ограничить доступ ACL-политикой.

Не анонсируйте всю домашнюю или офисную сеть без необходимости. Разрешайте только то, что действительно нужно.

DERP и Headscale

DERP нужен как relay, когда устройства не могут построить прямое соединение. Это не основной путь для всего трафика и не полноценная замена хорошей сети. DERP помогает связности, но если весь трафик постоянно идет через relay, скорость может быть ниже.

Варианты:

использовать публичные DERP-серверы Tailscale, если схема это допускает;
настроить собственный DERP-сервер;
использовать embedded DERP, если это подходит вашему случаю;
разместить DERP ближе к пользователям;
не усложнять DERP до тех пор, пока нет реальной проблемы со связностью.

Самостоятельный DERP — это еще один сервис, который нужно обслуживать. Он должен быть доступен, иметь правильный TLS, открытые порты и нормальную сетевую локацию. Не добавляйте его “для красоты”. Добавляйте, если прямые соединения часто не строятся или latency через существующие relay плохой.

Headscale UI: нужен ли веб-интерфейс

Headscale исторически больше CLI-first. Есть сторонние веб-интерфейсы и админки, но их нужно оценивать отдельно: активность проекта, безопасность, поддержка версии Headscale, авторизация, reverse proxy, доступ из интернета.

UI может быть удобен для просмотра nodes, routes и users, но не должен становиться новой дырой в безопасности.

Если ставите UI:

не открывайте его публично без авторизации;
держите за VPN, Tailscale/Headscale-сетью или allowlist IP;
обновляйте вместе с Headscale;
проверяйте совместимость версий;
не давайте UI больше прав, чем нужно;
не храните токены в открытом виде.

Для первого production-запуска Headscale лучше сначала добиться стабильной CLI-схемы, backup и подключения клиентов. UI можно добавить позже.

Безопасность Headscale на VPS

Headscale — критичная часть вашей приватной сети. Если control server скомпрометирован, злоумышленник может влиять на регистрацию устройств и сетевую конфигурацию. Поэтому безопасность здесь важнее, чем в обычном тестовом сервисе.

Минимальный набор:

SSH по ключам;
отдельный sudo-пользователь;
обновленная система;
firewall;
только нужные публичные порты;
TLS через нормальный reverse proxy;
backup базы Headscale;
backup config.yaml;
ограничение доступа к UI;
регулярная проверка nodes и keys;
удаление старых устройств;
аккуратное хранение pre-auth keys.

Не используйте VPS с Headscale как помойку для случайных сервисов. Чем больше лишнего на control server, тем выше риск. Идеально — отдельный VPS под Headscale и связанные сетевые сервисы.

Какие порты открывать

Для Headscale обычно нужен HTTPS-доступ через 443/tcp к control server. Если вы добавляете DERP, exit node, DNS или другие сервисы, порты зависят от выбранной схемы.

Базовая логика firewall:

22/tcp для SSH, лучше ограничить по IP или использовать ключи;
80/tcp временно или для Let's Encrypt HTTP challenge, если используется;
443/tcp для Headscale через reverse proxy;
дополнительные DERP-порты только если реально используется DERP;
никаких открытых баз данных наружу;
никаких публичных админок без защиты;
никаких случайных test-портов.

Проверка открытых портов на VPS:

ss -tulpn

Проверка firewall, если используется UFW:

ufw status verbose

Если вы не можете объяснить, зачем открыт конкретный порт, он должен быть закрыт.

Backup Headscale

Backup — обязательная часть. Потеря базы Headscale может означать потерю состояния nodes, users, keys и сетевой конфигурации. Это не тот сервис, который стоит держать без копий.

Что нужно сохранять:

конфигурационный файл Headscale;
базу данных SQLite или дамп PostgreSQL;
ACL-файлы;
reverse proxy конфиг;
systemd unit или docker compose файл;
документацию по users, routes и exit nodes;
секреты и ключи в безопасном хранилище.

Если используется SQLite, backup обычно проще: остановить сервис или сделать корректную копию базы безопасным способом, затем сохранить файл в отдельное место. Если используется PostgreSQL, нужен регулярный dump и проверка восстановления.

Не считается backup-ом файл на том же VPS. Если сервер удален, диск сломан или учетная запись потеряна, локальная копия не поможет.

Обновления Headscale

Headscale и Tailscale-клиенты развиваются. Поэтому нельзя поставить сервер и забыть о нем на год. Перед обновлениями читайте release notes, делайте backup и проверяйте совместимость клиентов.

Правильная схема обновления:

сделать backup базы и конфигов;
проверить текущую версию;
прочитать изменения новой версии;
обновить сначала тестовый узел, если инфраструктура важная;
обновить Headscale;
проверить регистрацию нового клиента;
проверить существующие nodes;
проверить routes, ACL, MagicDNS и exit node;
проверить логи после обновления.

Не обновляйте control server вслепую перед важной поездкой, релизом или рабочей сменой. Если он сломается, вы можете потерять доступ к приватной сети в неподходящий момент.

Мониторинг Headscale

Control server должен быть наблюдаемым. Даже если трафик между уже подключенными устройствами может продолжать работать какое-то время, регистрация новых устройств, обновление карты сети и управление nodes зависят от control server.

Минимально мониторьте:

доступность HTTPS endpoint;
статус сервиса Headscale;
статус reverse proxy;
срок действия TLS-сертификата;
место на диске;
RAM и CPU;
ошибки в логах;
успешность backup;
наличие старых или неизвестных nodes;
доступность DERP, если он используется.

Если Headscale используется для команды, мониторинг обязателен. Иначе вы узнаете о проблеме только когда кто-то не сможет подключиться.

Типовые ошибки при Headscale self-hosted

Ошибка 1. Думать, что Headscale — это обычный VPN-сервер.

Headscale — это control server. Для exit node, subnet routes, DNS и relay нужны отдельные настройки.

Ошибка 2. Ставить без домена и нормального TLS.

Custom control server должен быть доступен клиентам по корректному URL. Кривой TLS и временные домены быстро ломают подключение клиентов.

Ошибка 3. Открыть админку и UI в интернет.

Любой UI или admin endpoint нужно защищать. Лучше держать доступ через VPN, allowlist IP или сильную авторизацию.

Ошибка 4. Не делать backup базы.

Без backup потеря VPS может превратиться в пересборку всей tailnet-сети.

Ошибка 5. Подключать все устройства без нормальных имен.

Через месяц вы не поймете, какой node кому принадлежит и что можно удалить.

Ошибка 6. Не использовать ACL, когда сеть выросла.

Для двух личных устройств полный доступ терпим. Для команды, серверов и subnet routes — уже нет.

Ошибка 7. Ставить Headscale в Docker без понимания сетей и volume.

Docker удобен, если вы умеете его обслуживать. Иначе можно потерять данные, сломать reverse proxy или неправильно пробросить порты.

Ошибка 8. Сразу строить сложную схему с DERP, UI, AdGuard, exit node и routes.

Сначала поднимите Headscale, подключите клиентов, проверьте базовую связность. Потом добавляйте сложные функции по одной.

Что делать, если клиент не подключается к Headscale

Проверяйте по слоям.

Домен Headscale указывает на правильный IP VPS.
HTTPS endpoint открывается снаружи.
TLS-сертификат корректный.
Reverse proxy проксирует на Headscale.
Headscale service запущен.
В логах нет ошибок конфигурации.
Клиент действительно использует custom control server URL.
Registration URL или pre-auth key актуальны.
Устройство не было уже зарегистрировано в другой сети конфликтующим способом.
Версия Tailscale client поддерживает нужный сценарий.

Команды для базовой диагностики на VPS:

systemctl status headscale

journalctl -u headscale --no-pager -n 100

ss -tulpn

curl -I https://your-headscale-domain.example

Если HTTPS снаружи не работает, клиент не подключится. Сначала чините домен, TLS и reverse proxy, а уже потом Headscale.

Что делать, если устройства зарегистрированы, но не видят друг друга

Если nodes есть в Headscale, но между ними нет связи, проблема может быть в маршрутах, ACL, firewall, клиентской ОС или NAT traversal.

Проверьте:

оба устройства онлайн;
оба подключены к одному Headscale server;
ACL не запрещает трафик;
firewall на самих устройствах не блокирует входящие соединения;
ping по Tailscale IP;
DNS-имена, если используется MagicDNS;
логи клиента Tailscale;
нужен ли DERP relay для этой пары устройств;
не конфликтуют ли локальные подсети.

Не начинайте сразу менять сервер. Если control plane работает и nodes зарегистрированы, проблема часто на стороне политики, клиента или сети между устройствами.

Что делать, если routes или exit node не работают

Routes и exit node не начинают работать только потому, что node подключен. Их нужно advertise, approve и правильно настроить на самом узле.

Проверяйте:

node advertised нужную route или exit node;
route одобрена в Headscale;
на Linux-узле включен IP forwarding;
firewall не блокирует forwarded traffic;
клиент выбрал exit node, если нужен единый выход;
нет конфликта подсетей;
DNS настроен ожидаемо;
ACL разрешает нужный трафик.

Самая частая ошибка — ждать, что Headscale сам “проложит весь интернет”. Нет. Он управляет маршрутом на уровне control plane, но Linux-сервер, firewall и клиентские настройки должны быть корректными.

Headscale для команды: где начинаются риски

Для личного использования Headscale может быть довольно простым. Для команды требования выше.

Нужно заранее решить:

кто администрирует Headscale;
как добавляются пользователи;
как отзывается доступ бывших сотрудников;
какие устройства разрешены;
какие ACL применяются;
какие subnet routes доступны;
кто может использовать exit node;
где хранятся backup и ключи;
как обновляется сервер;
что делать при падении VPS.

Не используйте один общий пользовательский доступ на всю команду. Это плохая практика. Каждое устройство должно быть понятно названо, а доступ должен отзываться без пересборки всей сети.

Headscale или Tailscale hosted: что выбрать

Hosted Tailscale проще: меньше администрирования, готовый control plane, понятная панель, меньше ответственности за сервер. Для многих пользователей это лучший выбор.

Headscale лучше, когда есть конкретная причина self-hosted control server:

вы хотите держать control plane у себя;
вы строите homelab или small org network;
вы готовы обслуживать VPS;
вам подходит scope одного tailnet;
вы готовы сами решать backup, TLS, updates и monitoring;
вы хотите open-source control server;
вы понимаете ограничения по клиентам, функциям и поддержке.

Если вы не можете объяснить, зачем вам именно Headscale, выбирайте обычный Tailscale или классический VPN. Self-hosted не всегда лучше. Self-hosted просто переносит контроль и ответственность к вам.

Какой VPS выбрать в HSTQ для Headscale

Для Headscale self-hosted в HSTQ подойдет VPS/VDS с публичным IPv4, чистой Ubuntu или Debian, стабильной сетью и возможностью быстро переустановить ОС. Для личной сети достаточно небольшого VPS, но для команды, DERP, UI, DNS, exit node или дополнительных сервисов лучше брать запас по RAM и трафику.

При выборе тарифа смотрите не только на цену. Для control server важны стабильность, публичный IP, нормальный uptime, доступ к панели управления, возможность backup/snapshot и помощь с первичной настройкой. Если Headscale станет центральной точкой вашей приватной сети, экономить на случайном минимальном VPS — слабое решение.

Посмотреть VPS/VDS можно здесь: https://cp.hstq.net/store/vps-vds-nmve.

Если нужна помощь с подбором или настройкой, лучше сразу указать: сколько устройств будет в tailnet, какие платформы нужны, будет ли exit node, нужны ли subnet routes, нужен ли DERP, нужен ли Headscale UI, планируется ли команда или только личная сеть, какой домен будет использоваться для control server.

Практический чек-лист перед запуском

Есть отдельный VPS с публичным IPv4.
Есть домен или поддомен для Headscale.
DNS-запись указывает на VPS.
Настроен TLS через reverse proxy.
Headscale не торчит наружу на лишних портах.
SSH защищен ключами.
Firewall закрывает все лишнее.
Выбран тип базы: SQLite или PostgreSQL.
Настроен backup базы и конфигов.
Создан понятный user/namespace.
Тестовый Linux-клиент подключен успешно.
Проверен Windows/macOS/iOS/Android-клиент, если они нужны.
Устройства видят друг друга по Tailscale IP.
ACL не оставлены хаотично открытыми, если сеть не личная.
Routes и exit node проверены отдельно, если они используются.
Есть план обновления и восстановления.

Headscale на VPS — сильное решение, если вам нужен свой self-hosted control server для Tailscale-сети. Но это не “бесплатный Tailscale без ответственности”. Это инфраструктурный сервис, который нужно аккуратно развернуть, защитить, мониторить и обновлять.

Правильная схема начинается просто: отдельный VPS, домен, HTTPS через reverse proxy, Headscale, backup, один тестовый клиент, затем остальные устройства. Только после базовой стабильности стоит добавлять ACL, MagicDNS, subnet routes, exit node, DERP, UI и DNS-фильтрацию. Так self-hosted Headscale становится управляемой сетью, а не новым источником хаоса.

Categories