Як запустити subnet router Tailscale на VPS

Що робить subnet router у Tailscale

subnet router у Tailscale — це одна машина, яка анонсує tailnet цілий діапазон приватних IP-адрес. Тому кожен пристрій у tailnet може звертатися до адрес у цьому діапазоні, навіть якщо на жодному пристрої в ньому не запущено Tailscale. tailnet — це ваша приватна мережа Tailscale: набір пристроїв, авторизованих в одному обліковому записі або організації. З subnet router часто плутають exit node, але він виконує протилежне завдання. Exit node передає весь трафік пристрою через VPS, тому VPS стає маршрутом цього пристрою до публічного інтернету.

Коротко: subnet router робить одну приватну мережу доступною з tailnet. Exit node змінює точку виходу вашого публічного трафіку в інтернет. Якщо вам потрібен другий варіант, прочитайте як запустити exit node Tailscale на VPS. Це окремі прапорці. Один VPS може одночасно виконувати обидві функції, але вони вирішують різні завдання та мають різні причини збоїв.

Коли VPS потрібен як маршрутизатор підмережі

Поширений випадок — приватна мережа, яку вже надав провайдер. Ваш VPS має публічну адресу та другий інтерфейс у приватному сегменті, а інші сервери в цьому сегменті взагалі не мають публічних адрес: база даних за адресою 10.0.0.20, ціль для резервних копій за адресою 10.0.0.30. Встановіть Tailscale на один VPS і оголосіть 10.0.0.0/24. Після цього ноутбук зможе напряму звертатися до цих приватних адрес. На самому сегменті нічого змінювати не потрібно, а база даних і далі не матиме публічної адреси.

Інший випадок — мережа на віддаленому боці VPS. Це може бути домашня або офісна LAN за власним маршрутизатором чи стійка з пристроями, на яких неможливо запустити Tailscale, наприклад керований комутатор або старий NAS із заблокованою прошивкою. Один Linux-комп’ютер у цій мережі стає маршрутизатором підмережі для всіх інших пристроїв у ній.

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

Встановіть Tailscale і спочатку перевірте локальний маршрут

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

Скрипт визначає дистрибутив, додає репозиторій пакетів Tailscale, встановлює команду tailscale і daemon tailscaled, а потім вмикає сервіс. Перевірте це командою systemctl is-active tailscaled. Вона має вивести active.

Перш за все переконайтеся, що VPS може досягти мережі, яку ви плануєте анонсувати.

ip route show
ping -c3 10.0.0.20

Команда ip route show має показати приватний діапазон на реальному інтерфейсі, наприклад 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. Якщо ping не проходить уже на цьому етапі, безпосередньо до маршрутизатора, жоден прапорець Tailscale не допоможе. Проблема в мережевій конфігурації VPS або у firewall на цільовому хості. Спочатку усуньте її, оскільки від цього залежать усі наступні перевірки.

Увімкніть IP forwarding і збережіть налаштування після перезавантаження

Linux-комп’ютер відкидає всі пакети, адресовані не йому, якщо forwarding вимкнено. Передавання пакетів інших комп’ютерів є основним завданням subnet router, тому цей крок обов’язковий.

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

Перевірте налаштування командою sysctl net.ipv4.ip_forward. Вона має вивести net.ipv4.ip_forward = 1.

Цей крок часто виконують лише частково. sudo sysctl -w net.ipv4.ip_forward=1 починає працювати одразу, але його налаштування зникає після наступного завантаження. Тому subnet router може працювати тижнями, а потім перестати працювати вранці після перезавантаження через оновлення kernel. Проблему важко помітити, оскільки зовні все виглядає нормально. tailscale status і далі показує node як доступний, admin console показує схвалений маршрут, а клієнти все ще мають встановлений маршрут. Пакети надходять до VPS, але kernel відкидає їх без запису в журнал. Запис значень у /etc/sysctl.d/99-tailscale.conf дає змогу відновити їх після перезавантаження.

Якщо ви оголосите маршрути, коли forwarding усе ще вимкнено, tailscale up попередить про це одразу. У виводі з’явиться рядок, подібний до Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly.. Прочитайте вивід цієї команди, а не пропускайте його.

Оголосіть маршрути

sudo tailscale up --advertise-routes=10.0.0.0/24

На VPS, який уже підключений до вашого tailnet, натомість змініть параметр безпосередньо:

sudo tailscale set --advertise-routes=10.0.0.0/24

Для всіх подальших змін використовуйте tailscale set. Повторний запуск tailscale up з одним прапорцем скидає прапорці, які ви не вказали повторно, а CLI зупиняє виконання з помилкою про те, що для зміни параметрів у такий спосіб потрібно вказати всі прапорці, що не мають значень за замовчуванням. tailscale set змінює один параметр і залишає решту без змін.

Кілька діапазонів потрібно вказати одним списком, розділяючи їх комами без пробілів: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Кожен запис має бути мережевою адресою в нотації CIDR (classless inter-domain routing, формат 10.0.0.0/24). Якщо помилково вказати власну адресу хоста, 10.0.0.5/24, команду буде відхилено, оскільки біти після префікса не дорівнюють нулю, а повідомлення про помилку назве префікс, який, імовірно, ви мали на увазі. Щоб припинити оголошення маршрутів, задайте порожній список за допомогою sudo tailscale set --advertise-routes=.

Схвалення маршруту в адміністративній консолі

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

Схваліть маршрут на сторінці Machines в адміністративній консолі. VPS буде позначено бейджем subnet. Відкрийте його рядок, знайдіть розділ subnets, відредагуйте параметри маршруту, установіть прапорець для маршруту та збережіть зміни.

Схвалення виконується окремо для кожного префікса. Якщо сьогодні анонсувати 10.0.0.0/24, а наступного місяця — 192.168.50.0/24, новий префікс залишиться несхваленим, а старий продовжить працювати. Для VPS схвалений і проігнорований маршрути виглядають однаково, тому перед будь-якою іншою діагностикою перевірте адміністративну консоль.

Ручний крок можна пропустити, додавши блок autoApprovers до файлу політики tailnet:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

Потім запустіть вузол із цим тегом, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, і маршрут буде схвалено одразу після анонсування. Спочатку тег має існувати в розділі tagOwners того самого файлу політики. Це варто налаштувати, якщо ви відновлюєте VPS зі скрипту, оскільки відновлений вузол є новим вузлом, а його маршрути знову починають роботу в несхваленому стані.

Чому клієнти Linux ігнорують маршрут без --accept-routes

Маршрут уже оголошено й підтверджено. Ваш телефон і Mac можуть підключитися до 10.0.0.20. Ноутбук із Linux — ні, і в адміністративній консолі немає ознак проблеми.

Прийняття маршруту підмережі означає додавання записів до таблиці маршрутизації клієнта. В Android, iOS, macOS, tvOS і Windows клієнт Tailscale робить це автоматично. У Linux цього не відбувається, оскільки машина з Linux часто є сервером або маршрутизатором із навмисно налаштованою таблицею маршрутизації. Тихе додавання /24, отриманого з мережі, може порушити обробку трафіку, за яку ця машина вже відповідає. Тому в Linux потрібно явно дозволити маршрутизацію на кожному клієнті:

sudo tailscale set --accept-routes

Потім перевірте, куди додано маршрут:

ip route show table 52
ip route get 10.0.0.20

Tailscale у Linux не додає прийняті маршрути до основної таблиці маршрутизації. Він додає їх до таблиці маршрутизації 52 і встановлює policy rules. Їх можна побачити за допомогою ip rule show у діапазоні пріоритетів від 5210 до 5270. Ці правила передають пакети, для яких не знайдено відповідності, до цієї таблиці. Тому ip route show сам по собі ніколи не покаже 10.0.0.0/24, і читач, який перевіряє лише цю команду, робить висновок, що --accept-routes нічого не зробив. Команда ip route show table 52 показує фактичний стан. У її виведенні має бути оголошений діапазон для tailscale0.

Варто знати про один виняток. Якщо цей вузол Linux сам є другим subnet router для власної локальної мережі, --accept-routes змушує його передавати трафік до власної безпосередньо підключеної підмережі через інший маршрутизатор, а не через власний інтерфейс. На резервному маршрутизаторі в парі високої доступності залиште --accept-routes вимкненим і оголошуйте лише потрібні маршрути.

Режим відмови: два маршрутизатори рекламують діапазони, що перекриваються

Два subnet routers не повинні рекламувати однакові діапазони. Діапазони, що перекриваються та мають різну довжину префікса, дозволені, і Tailscale вибирає найбільш специфічний збіг. Якщо маршрутизатор A рекламує 10.0.0.0/24, а маршрутизатор B — 10.0.0.0/16, трафік до 10.0.0.20 надходить через A.

Проблема виникає, коли A переходить в офлайн. Tailscale не перемикається на маршрут із меншою специфічністю. Трафік до 10.0.0.20 зупиняється, а трафік до 10.1.0.20 і далі працює через B. Симптом виглядає так, ніби половина приватної мережі недоступна. Причина полягає в тому, що один офлайн-вузол утримує специфічніший префікс. Якщо потрібне перемикання на резервний маршрут, налаштуйте ширший маршрутизатор так, щоб він також рекламував вужчі префікси. Тоді обидва маршрутизатори охоплюватимуть однакові адреси.

Інше перекриття виникає ближче до клієнта. Якщо ви перебуваєте в готельній мережі з адресою 192.168.1.0/24, а ваш subnet router рекламує 192.168.1.0/24, вони конкурують за ті самі призначення. Який маршрут переможе, залежить від платформи. У Linux додайте правило перед правилом самого Tailscale, щоб локальні адреси використовували main table:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

Це правило не є постійним і зникне після наступного завантаження. Правильне рішення — вибрати приватний діапазон, з яким ви не стикатиметеся в інших мережах. 192.168.0.0/24 і 192.168.1.0/24 є типовими діапазонами більшості домашніх маршрутизаторів, тому виберіть діапазон усередині 10.0.0.0/8 свідомо. Те саме перекриття порушує роботу звичайної VPN WireGuard, налаштованої вручну, з тієї самої причини: специфічніший локальний маршрут перемагає, тому трафік не потрапляє в тунель.

Режим відмови: DNS перетворює ім’я на адресу, для якої немає відповідного маршруту

Цей випадок складно діагностувати, оскільки жодна система не повідомляє про помилку. Ім’я успішно перетворюється на адресу. Час очікування підключення спливає.

Припустімо, що db.internal.example.com через ваш приватний nameserver перетворюється на 10.0.5.20, а ви оголосили 10.0.0.0/24. Пошук успішний, оскільки розпізнавання DNS (системою доменних імен) і IP-маршрутизація є окремими етапами, і жоден із них не перевіряє інший. Тоді пакет до 10.0.5.20 не знаходить відповідного маршруту в tailnet, виходить через стандартний шлюз клієнта й зникає.

Дві команди дають змогу перевірити ці етапи окремо:

nslookup db.internal.example.com
ip route get 10.0.5.20

Якщо пошук повертає адресу, але ip route get не відповідає на dev tailscale0, ім’я налаштоване правильно, а маршрут відсутній. Оголосіть діапазон, який охоплює цю адресу: 10.0.0.0/16 або другий явний префікс. Потім схваліть новий префікс у консолі.

На самому nameserver є аналогічна проблема. Якщо в адміністративній консолі ви вказали глобальний nameserver за приватною адресою, наприклад 10.0.0.53, ця адреса має входити до схваленого маршруту. Інакше пристрої взагалі не зможуть підключитися до резолвера. Якщо увімкнути параметр, який замінює локальні DNS-сервери, і вказати резолвер, до якого ніхто не може дістатися, усі пристрої в tailnet одночасно втратять розпізнавання імен, зокрема ті, що ще секунду тому працювали. Спочатку оголосіть і схваліть маршрут до резолвера, а потім змініть налаштування DNS. Якщо ви постійно стикаєтеся з проблемами DNS усередині тунелю, у матеріалі як DNS працює неправильно через тунель WireGuard описано той самий механізм без додаткового координаційного рівня.

Source NAT і site-to-site з’єднання

За замовчуванням subnet router замінює адресу джерела кожного пересланого пакета на власну приватну адресу. Це SNAT (source network address translation). Такий режим потрібен, щоб відповіді працювали без змін у приватній мережі: база даних на 10.0.0.20 відповідає VPS, маршрут до якого їй уже відомий. Недолік у тому, що база даних бачить кожне tailnet-з’єднання як підключення з VPS. Тому правила firewall за адресою джерела та журнали доступу не дають корисної інформації.

Вимкніть SNAT у Linux, якщо потрібно зберегти справжню tailnet-адресу клієнта:

sudo tailscale set --snat-subnet-routes=false

Хости в приватній мережі тоді потребують зворотного маршруту до 100.64.0.0/10 — діапазону адрес, який Tailscale призначає пристроям. Цей маршрут має вказувати на subnet router. Без нього відповіді надходитимуть до шлюзу за замовчуванням і не дійдуть до джерела. Через це з’єднання зависатиме після першого пакета. Додайте статичний маршрут на шлюзі приватної мережі або залиште SNAT увімкненим.

Site-to-site з’єднання — це два subnet router, які одночасно виконують цю операцію: кожен оголошує власну мережу та приймає маршрути до мережі іншого:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

Виконайте відповідну команду на іншому router, указавши його власний діапазон. Діапазони мають бути різними. Якщо великі передавання зависають, а ssh і ping працюють, причина, імовірно, у MSS (maximum segment size) — максимальному обсязі даних, який переносить TCP-пакет. Накладні витрати тунелю роблять переслані пакети завеликими для певної ділянки мережі. Обмеження MSS усуває цю проблему:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Збережіть це правило за допомогою iptables-persistent. Інакше воно зникне після наступного завантаження системи.

Підтримка працездатності

Станом на August 2026 термін дії ключів вузлів за замовчуванням становить 180 days. Коли термін дії ключа на subnet router завершується, вузол виходить із системи, а весь оголошений діапазон стає недоступним. При цьому в конфігурації немає змін, які могли б це пояснити. На сторінці Machines в адміністративній консолі вимкніть завершення терміну дії ключа для цієї машини. Зафіксуйте, що ви це зробили.

Tailscale надає перевагу прямому з’єднанню між вузлами й переходить на свої relay-сервери, якщо встановити пряме з’єднання не вдається. Relay-сервери працюють, але додають затримку. VPS із публічною адресою — найпростіший випадок: дозвольте вхідний UDP-трафік на порт 41641, і більшість вузлів зможуть підключатися напряму. Якщо firewall налаштовує ufw, у правилах ufw, які фактично потрібні VPS наведено відповідний синтаксис.

Правила доступу — інша важлива частина конфігурації. У tailnet за замовчуванням кожен ваш пристрій може підключатися до будь-якого іншого, тому затверджений маршрут працює без додаткових налаштувань. Після створення ACL-політики в destination-частині правила потрібно вказати приватний діапазон, оскільки 10.0.0.20 не є адресою tailnet і на нього не поширюються правила, написані для tailnet IP-адрес або тегів.

Нарешті, вирішіть, чи потрібен вам coordination server, яким ви не керуєте самостійно. Control plane Tailscale — це hosted service. Ваші ключі зберігаються на ваших машинах, але обліковий запис і файл політики розміщені в цьому сервісі. Запуск Headscale, self-hosted control server для Tailscale дає змогу розмістити їх на власному VPS, але потребує самостійного обслуговування. Інший варіант для тієї самої проблеми — відмовитися також від клієнтів Tailscale і розмістити VPN-сервер NetBird у власній інфраструктурі. Так coordination layer і власні mesh-клієнти працюють на одній машині під вашим контролем. Якщо ви ще обираєте між цією моделлю та конфігурацією, написаною вручну, порівняння WireGuard і Tailscale пояснює, які можливості дає coordination layer і якою є його вартість.

FAQ

У чому різниця між subnet router і exit node?

Subnet router оголошує діапазон приватних адрес, тому пристрої tailnet можуть підключатися до машин, на яких не запущено Tailscale. Exit node оголошує себе маршрутом до всього інтернету, тому пристрій надсилає весь мережевий трафік через публічну адресу цього вузла. Один VPS може виконувати обидві ролі. Це окремі прапорці, --advertise-routes і --advertise-exit-node, і кожен із них потрібно окремо схвалити в консолі адміністратора.

Чому мій Linux-клієнт ігнорує оголошений маршрут subnet?

Linux-клієнти не приймають маршрути subnet без явного дозволу. Виконайте на клієнті sudo tailscale set --accept-routes. Потім перевірте результат за допомогою ip route show table 52, а не ip route show. Tailscale встановлює прийняті маршрути в таблицю маршрутизації 52 і використовує для доступу до них policy rules, тому в основній таблиці вони не відображаються, і робочий маршрут може виглядати відсутнім.

Мій subnet перестав працювати після перезавантаження. Що сталося?

Найімовірніше, вимкнулася IP forwarding. Значення, задане за допомогою sysctl -w, не зберігається після перезавантаження, тому запишіть його в /etc/sysctl.d/99-tailscale.conf і перевірте за допомогою sysctl net.ipv4.ip_forward. Якщо forwarding увімкнено, але діапазон усе ще недоступний, перевірте вузол у консолі адміністратора. Типово ключі вузлів мають строк дії 180 days, і прострочений subnet router виглядає як мережева проблема, а не як проблема облікового запису.

Чи можуть два subnet routers оголошувати один і той самий діапазон?

Ідентичні діапазони — ні. Діапазони, що перетинаються, але мають різну довжину префікса, допустимі; пріоритет має найбільш специфічний маршрут. Для failover потрібна обережність: коли router із більш специфічним префіксом вимикається, Tailscale не переходить на ширший маршрут, тому цей трафік зупиняється. Для справжньої пари standby налаштуйте обидва routers на оголошення однакових специфічних префіксів.

Ім’я хоста визначається, але підключення завершується тайм-аутом. Чому?

DNS-розв’язання та маршрутизація — це окремі етапи. Ім’я може визначатися в адресу, для якої немає схваленого маршруту, і тоді пакет виходить через шлюз за замовчуванням клієнта. Виконайте на клієнті ip route get <address>. Якщо відповідь не містить dev tailscale0, оголосіть діапазон, що охоплює цю адресу, і схваліть новий префікс у консолі адміністратора.