Tailscale: VPN без болю та помилки доступу, які все ще шкодять

Що насправді таке Tailscale (і чого ні)

Tailscale — це накладна мережа на базі WireGuard, яка прив’язує зʼєднання до ідентичності.
Ви отримуєте приватний діапазон IP (зазвичай 100.64.0.0/10), вузли автентифікуються через провайдера ідентичності,
а плейн керування координує ключі й маршрути, щоб пристрої могли спілкуватися напряму, коли це можливо.

Важлива ментальна модель: Tailscale — це не «VPN-сервер». Це розподілена сітка з координаційним шаром.
Більшість трафіку — peer-to-peer. Якщо це неможливо (NAT, фаєрволи, симетричний NAT тощо), трафік ретранслюється через DERP.
DERP — не «задній хід»; це прагматичний ретранслятор, щоб ваш ноутбук міг дістатися до машини в старому дата-центрі.

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

І так, ви все ще можете себе закрити зсередини. Tailscale просто допомагає зробити це швидше й з більшої кількості місць.

Факти та історія, які варто знати

• WireGuard — молодий у порівнянні з VPN. Він опинився в основній гілці Linux у 2020 році, що має значення в порівнянні зі старими IPsec-стеками.
• За замовчуванням адресний простір Tailscale (100.64.0.0/10) належить до діапазону CGNAT, зменшуючи колізії з внутрішніми мережами RFC1918 — зазвичай.
• DERP — це ретранслятор, а не концентратор тунелів. Він існує, щоб обробляти випадки, коли обхід NAT не вдається інакше заблокує зʼєднання.
• «Zero trust» став рядком у бюджеті після того, як моделі лише з периметром постійно давали збій у гібридному хмарному + віддаленому середовищі.
• Традиційні VPN нормалізували загальні секрети й статичні конфіги (профілі клієнтів, PSK, довгоживучі сертифікати). Tailscale штовхає до короткоживучої аутентифікації, привʼязаної до ідентичності.
• Розщеплення тунелю бʼє по старим інстинктам. Багато корпоративних VPN змушували «весь трафік через штаб-квартиру»; Tailscale робить це опціональним через exit nodes, навмисно.
• ACL тепер — політика як код. Це чудово — доки хтось не ставитиме файл ACL як магічне заклинання замість межі безпеки.
• Підмережна маршрутизація існувала до Tailscale. Накладна маршрутизація спокушає «просто промаршрутувати весь дата-центр», а це шлях до аудиту.
• Провайдери ідентичності стали новим периметром, тому відмова IdP може відчуватися як мережевий збій у костюмі.

Здорова база налаштування «VPN без болю»

Якщо ви хочете, щоб Tailscale залишався нудним, вирішіть, що означає «нудний», перш ніж клацати будь-які перемикачі.
Моя дефініція: інженери можуть дістатися до потрібного, доступ за замовчуванням мінімальний,
а режим відмови — «не можу підключитися», а не «підключився до всього».

Почніть з мінімальної топології

Не починайте з підмереж, exit nodes і хитрих виключень на основі тегів у перший тиждень.
Почніть зі зʼєднання пристрій-до-пристрою серед невеликого набору адмінських робочих станцій і кількох цільових хостів.
Підтвердіть продуктивність, підтвердіть потік ідентичності, підтвердіть логи. Потім масштабуйте.

Виберіть історію ідентичності і дотримуйтеся її

Якщо ви використовуєте IdP (Google Workspace, Microsoft Entra ID, Okta тощо), вимагайте MFA і довіру до пристрою де можливо.
IdP тепер — ваш «вхід у VPN». Ставтеся до нього як до критичного для продакшену.
Якщо в організації алергія на SSO, використовуйте auth keys Tailscale — але розумійте життєвий цикл, ротацію і область дії.

Визначте, як вузли отримують авторизацію

Для продакшен-середовищ надавайте перевагу моделі, де:

• Користувачі не можуть просто додавати випадкові пристрої без затвердження (або хоча б без видимості).
• Сервери реєструються зі скоупованими, повторно використовуваними auth keys (або одноразовими епhemeral keys) плюс теги.
• Деактивація користувача або пристрою — одна дія, яка дійсно працює.

Зробіть мережевий план явним

Накладні мережі підштовхують до рішень «тільки цього разу», які стають постійними.
Запишіть:

• Які сервіси мають бути доступні (SSH, RDP, Postgres, внутрішні веби тощо).
• З яких ролей (on-call, CI, DBA, support).
• Чи будете використовувати підмережні маршрути, чи вимагати встановлення Tailscale на самих хостах.
• Чи дозволятимете exit nodes і для кого.

Жарт №1: VPN — як спільна кухня в офісі — якщо ви не маркуєте речі, хтось вип’є молоко, і це буде ваш збій.

Ідентичність, ACL, теги: де доступ працює або ламається

Велика перевага Tailscale — водночас і його найбільша пастка: контроль доступу стає настільки простим, що люди перестають думати.
У класичному світі VPN ви мали мережеву межу й купу правил фаєрвола. У світі Tailscale ACL — ваш фаєрвол.
Якщо ви ставитимете їх як «той конфіг файлик, що ми копіюємо», ви нашатаєте помилки в безпеці.

Використовуйте групи для людей, теги для машин

Практичне правило: люди належать до груп, сервери отримують теги.
Люди міняють роботу, звільняються, йдуть у відпустку і приносять персональні пристрої. Сервери не мають успадковувати людську ідентичність.
Теги показують ролі машин («tag:db», «tag:bastion», «tag:monitoring»).

Потім пишіть ACL так, ніби вам доведеться про них звітувати в суді.
Мінімальні привілеї. Явні порти. Ніяких широких правил «дозволити все», щоб «запустити».
Запустити — легко; зробити безпечно — це робота.

Уникайте «тимчасових» широких правил

Найнебезпечніше правило ACL — те, що додали під час інциденту.
Друге найнебезпечніше — те, що ніхто не памʼятає, що додали під час інциденту.
Покладіть на себе часовий тиск: якщо додаєте аварійне виключення, заплануйте його видалення, поки ще памʼятаєте, чому воно існує.

Думайте про blast radius

Якщо один ноутбук скомпрометовано, до чого він має доступ?
Якщо один auth key потрапає в руки, що він може зареєструвати?
Якщо IdP неправильно налаштовано, що отримає зловмисник?
Відповідайте на ці питання до того, як ваш аудитор поставить їх у спокійній кімнаті під флуоресцентним світлом.

Підмережі та вузли виходу: потужно, але легко зловживати

Підмережна маршрутизація дозволяє клієнтам Tailscale дістатися мереж, де не встановлено клієнт Tailscale.
Вузли виходу дозволяють направити інтернет-трафік клієнта через вузол Tailscale.
Обидві функції корисні в операціях. Обидві можуть тихо стати «новим корпоративним VPN» з усіма старими проблемами.

Підмережні маршрутизатори: коли й як

Використовуйте підмережні маршрутизатори для:

• Старих мереж, які ви не можете змінити (пристрої, старі гіпервізори, лабораторне обладнання).
• Короткострокових міграцій, коли встановлювати Tailscale скрізь нереалістично.
• Зʼєднань сайт-до-сайту, де ви хочете доступ на основі ідентичності, а не довіри на рівні сайту.

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

Вузли виходу: ставте як привілейовану інфраструктуру

Вузли виходу — не лише функція маршрутизації; це точки застосування політики й концентрації трафіку.
Якщо ви їх дозволяєте, контролюйте:

• Виділені, захищені вузли виходу (не «чийсь робочий стіл»).
• Обмежені ACL: тільки певні групи можуть їх використовувати.
• Моніторинг: пропускна здатність, CPU, втрата пакетів і чи клієнти несподівано використовують DERP.

Вузли виходу також ускладнюють реакцію на інциденти. Якщо ваш egress IP раптом «не той», можливо клієнт вибрав вузол виходу
(намерено або випадково). Це не мережева таємниця; це галочка.

DNS і MagicDNS: розвʼязування імен як фактор надійності

Більшість повідомлень «VPN впав» насправді — помилки DNS у мережевому вбранні.
MagicDNS Tailscale може впорядкувати це, давши стабільні імена вузлам і обробляючи split DNS для внутрішніх доменів.
Він також може створити нові режими відмови, якщо ви напівналаштуєте його.

Визначте, що означає «внутрішній DNS»

Якщо у вас вже є внутрішній DNS (Bind, Unbound, Infoblox, Route 53 private zones тощо), вирішіть, чи:

• Імен Tailscale достатньо (node-name.tailnet), або
• Вам потрібні внутрішні домени, розвʼязані через Tailscale (split DNS), або
• Вам потрібні обидва з чіткими правилами пріоритету.

Потім протестуйте на macOS, Windows, Linux і мобільних пристроях. DNS-стеки непослідовні; це зоопарк з паперами.

Tailscale SSH: видаляти ключі, а не відповідальність

Tailscale SSH може замінити традиційний розподіл SSH-ключів, привʼязуючи доступ по SSH до ідентичності Tailscale і політики.
Це привабливо: менше довгоживучих ключів, менше «хто відповідає за цей рядок в authorized_keys» і кращі трейли аудиту.
Це також зміна оперативних звичок.

Хороший підхід:

• Увімкніть Tailscale SSH спочатку на невеликому наборі хостів.
• Залиште break-glass доступ (консоль, cloud serial, out-of-band), бо ви рано чи пізно щось неправильно налаштуєте.
• Вирішіть, чи все ще дозволяєте openssh через мережі не-Tailscale. Зазвичай — ні.

Одна цитата про надійність, що досі справедлива: «Надія — не стратегія.» — генерал Гордон Р. Салліван.
Це не виключно ops-цитата, але вона болісно точна, коли ваш шлях доступу — один крихкий контрольний шар.

Практичні завдання: команди, виводи та рішення (12+)

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

Завдання 1: Перевірити, чи вузол справді підключений

cr0x@server:~$ tailscale status
100.64.10.12   web-01           linux   active; direct 198.51.100.24:41641, tx 123456 rx 234567
100.64.10.20   db-01            linux   active; relay "iad", tx 45678 rx 56789
100.64.10.99   cr0x-laptop      macOS   active; direct 203.0.113.77:54012, tx 98765 rx 87654

Значення: Якщо ви не бачите напарника, ви не в тому самому tailnet або напарник офлайн. «direct» vs «relay» показує шлях.

Рішення: Якщо піри відсутні, перевірте логін/авторизацію. Якщо зʼєднання ретранслюється несподівано, починайте шукати NAT/фаєрвол.

Завдання 2: Перевірити локальний демон та стан логіна

cr0x@server:~$ tailscale status --json | jq '.BackendState, .Self.DNSName, .Self.Online'
"Running"
"web-01.tailnet-abc.ts.net."
true

Значення: BackendState «Running» — добре. DNSName підтверджує, в якому tailnet ви.

Рішення: Якщо не працює — перезапустіть сервіс. Якщо DNSName неправильний — ви увійшли в іншу організацію.

Завдання 3: Підтвердити, які маршрути й налаштування DNS застосовані

cr0x@server:~$ tailscale netcheck
Report:
        * UDP: true
        * IPv4: yes, 198.51.100.24:41641
        * IPv6: no
        * MappingVariesByDestIP: false
        * HairPinning: true
        * Nearest DERP: iad
        * DERP latency:
                - iad: 18.2ms   (nearest)
                - ord: 35.4ms
                - lax: 72.9ms

Значення: UDP true — ключ для прямого WireGuard. Nearest DERP — куди ви будете ретранслюватись, якщо треба.

Рішення: Якщо UDP false — виправляйте фаєрвол/NAT. Якщо DERP latency велика — очікуйте повільніші інтерактивні сесії.

Завдання 4: Побачити активні налаштування (exit node, SSH, маршрути)

cr0x@server:~$ tailscale prefs
{
  "ControlURL": "https://controlplane.tailscale.com",
  "RouteAll": false,
  "ExitNodeID": "",
  "CorpDNS": true,
  "RunSSH": false
}

Значення: RouteAll false означає відсутність exit node. CorpDNS true — використовується конфігурація DNS tailnet.

Рішення: Якщо хтось каже «інтернет повільний», спочатку перевірте RouteAll/ExitNodeID. Часто це самозаподіяно.

Завдання 5: Підтвердити, що можна дістатися напарника по tailnet IP

cr0x@server:~$ ping -c 2 100.64.10.20
PING 100.64.10.20 (100.64.10.20) 56(84) bytes of data.
64 bytes from 100.64.10.20: icmp_seq=1 ttl=64 time=22.4 ms
64 bytes from 100.64.10.20: icmp_seq=2 ttl=64 time=22.1 ms

--- 100.64.10.20 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 22.141/22.262/22.384/0.121 ms

Значення: Базова досяжність працює.

Рішення: Якщо ping не проходить, але статус показує «active», підозрюйте ACL або локальний фаєрвол, що блокує ICMP (або ping відключено).

Завдання 6: Протестувати реальний порт сервісу (бо ping брешуть)

cr0x@server:~$ nc -vz 100.64.10.20 5432
Connection to 100.64.10.20 5432 port [tcp/postgresql] succeeded!

Значення: TCP-шлях до Postgres відкритий.

Рішення: Якщо це падає, але ping працює — це ACL або локальний фаєрвол чи сервіс не слухає на інтерфейсі tailnet.

Завдання 7: Перевірити, що сервіс слухає на правильних інтерфейсах

cr0x@server:~$ sudo ss -lntp | grep 5432
LISTEN 0      244          127.0.0.1:5432       0.0.0.0:*    users:(("postgres",pid=1342,fd=6))

Значення: Postgres привʼязаний лише до localhost. Tailscale не може дістатися до нього віддалено.

Рішення: Привʼяжіть до IP Tailscale або до 0.0.0.0 (з обмеженнями фаєрволу/ACL), потім перетестуйте.

Завдання 8: Переглянути таблицю маршрутизації Linux на предмет сюрпризів з підмережами

cr0x@server:~$ ip route show
default via 192.0.2.1 dev eth0
100.64.0.0/10 dev tailscale0 scope link
10.20.0.0/16 dev tailscale0 scope link

Значення: 10.20.0.0/16 маршрутується через tailscale0 — ймовірно, це підмережний маршрут, який ви прийняли.

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

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

cr0x@server:~$ tailscale status --json | jq '.Self.PrimaryRoutes, .Self.AdvertisedRoutes'
null
[
  "10.20.0.0/16"
]

Значення: Цей вузол рекламує 10.20.0.0/16 у tailnet.

Рішення: Якщо ви цього не планували, видаліть налаштування advertise-routes і змініть автоматизацію, що його поновлює.

Завдання 10: Перевірити, чи клієнт несподівано використовує DERP

cr0x@server:~$ tailscale ping 100.64.10.99
pong from cr0x-laptop (100.64.10.99) via DERP(iad) in 36ms

Значення: Ви ретранслюєтесь через DERP, а не напряму.

Рішення: Якщо продуктивність важлива, дослідіть UDP-доступність і поведінку NAT на обох кінцях.

Завдання 11: Перевірити лічильники фаєрвола на хості (приклад Linux nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    iif "lo" accept
    ct state established,related accept
    iif "tailscale0" tcp dport { 22, 5432 } accept
    counter packets 0 bytes 0 drop
  }
}

Значення: tailscale0 дозволено для портів 22 і 5432; політика drop для решти.

Рішення: Якщо лічильники показують зростання відкинутих пакетів під час тесту, виправте правила фаєрвола перед тим, як звинувачувати Tailscale.

Завдання 12: Перевірити розвязування DNS для імен MagicDNS

cr0x@server:~$ dig +short web-01.tailnet-abc.ts.net
100.64.10.12

Значення: Імʼя розвʼязується в IP tailnet.

Рішення: Якщо не розвʼязується, перевірте увімкнення MagicDNS і налаштування DNS клієнта; не витрачайте час на маршрути перш ніж це перевірити.

Завдання 13: Переглянути логи systemd сервісу для помилок авторизації та мережі

cr0x@server:~$ sudo journalctl -u tailscaled -n 50 --no-pager
Dec 27 11:02:14 web-01 tailscaled[812]: wgengine: Reconfig: configuring userspace WireGuard config (with 2 peers)
Dec 27 11:02:18 web-01 tailscaled[812]: magicsock: derp-https: connected to derp-iad
Dec 27 11:02:24 web-01 tailscaled[812]: health: state=running

Значення: Ви бачите нормальний підйом, зʼєднання з DERP і стан running.

Рішення: Якщо логи показують повторні помилки авторизації, прострочення ключів або «not authorized», зупиніться й виправте ідентичність/затвердження.

Завдання 14: Підтвердити узгодженість версій клієнта (щоб уникнути дивних багів)

cr0x@server:~$ tailscale version
1.76.6
  tailscale commit: 3f2c1a7e4
  go version: go1.22.6

Значення: Ви знаєте, що запускаєте.

Рішення: Якщо один сегмент на древній версії — оновіть перед глибокою діагностикою. Змішані версії породжують марні привиди.

Швидкий план діагностики

Коли зʼєднання ламається, треба швидко знайти шар-ґорло: ідентичність, політика, маршрутизація, транспорт або сам сервіс.
Ось порядок, який мінімізує марно витрачений час.

Першим: підтвердіть ідентичність і належність

• Чи показує tailscale status напарника взагалі?
• Чи вузол залогінений у правильний tailnet (суфікс DNSName)?
• Чи пристрій затверджено в адмін-консолі (якщо ввімкнено затвердження)?

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

Другим: підтвердіть політику (ACL, теги, SSH-політика)

• Чи можете ви пропінгувати tailnet IP?
• Чи можете ви підключитися до порту з nc -vz?
• Якщо використовуєте Tailscale SSH — чи увімкнено і дозвоено для цієї ідентичності?

Більшість продакшен-збоїв — це невідповідності політик: тег не застосувався, правило занадто широке (його посунули), або змінилася група.

Третім: підтвердіть транспорт (direct vs DERP, UDP-доступність)

• Запустіть tailscale netcheck і подивіться на UDP.
• Запустіть tailscale ping і подивіться, чи direct чи DERP.

Якщо це DERP і повільно — ви не «поза мережею», ви просто платите податок NAT. Виправлення NAT/фаєрвола може перетворити повільний віддалений шел на нормальний.

Четвертим: підтвердіть маршрутизацію (підмережі, exit nodes)

• Перевірте ip route на наявність несподіваних маршрутів через tailscale0.
• Перевірте, чи не увімкнено exit node (tailscale prefs).

Проблеми маршрутизації часто виглядають як «випадковий внутрішній сервіс зламався». Це не випадково; це детерміновано й недокументовано.

Пʼятим: підтвердіть сервіс і фаєрвол хоста

• Чи сервіс слухає на потрібному інтерфейсі (ss -lntp)?
• Чи фаєрвол дозволяє трафік tailscale0 (nftables/iptables)?

Якщо Tailscale у порядку, але сервіс привʼязаний до 127.0.0.1 — ваша накладна мережа ні до чого. Це нудна частина. Робіть її в будь-якому разі.

Типові помилки: симптом → корінь → виправлення

1) «Бачу вузол, але SSH таймаутиться»

Симптоми: Вузол в tailscale status. Ping може працювати. SSH/RDP/порт застосунку таймаутиться.

Корінь: Локальний фаєрвол блокує tailscale0, або сервіс слухає тільки localhost, або ACL блокує порт.

Виправлення: Перевірте nc -vz, потім ss -lntp, потім nftables/iptables. Переконайтеся, що ACL явно дозволяє порт призначення, і демон привʼязаний до доступного інтерфейсу.

2) «Сьогодні все повільне»

Симптоми: Інтерактивні сесії лагають; передача файлів повзає; періодичні затримки.

Корінь: Трафік ретранслюється через DERP через блокований UDP або симетричний NAT; іноді винен увімкнений exit node, що додає затримку.

Виправлення: Запустіть tailscale ping, щоб підтвердити DERP vs direct, і tailscale netcheck для UDP. Відкрийте вихідний UDP/41641 (або хоча б UDP загалом) у фаєрволі, і уникайте exit nodes для робіт, чутливих до затримки.

3) «Ми увімкнули підмережний маршрут і тепер дивні речі»

Симптоми: Деякі внутрішні IP маршрутуються інакше; сервіси стали доступні з місць, де не мали б бути; тікети про «split tunnel зламався».

Корінь: Клієнти прийняли підмережний маршрут, що перекривається з існуючими маршрутами, або широке префіксне оголошення (наприклад /16) там, де вистачило б /24.

Виправлення: Аудитуйте маршрути за допомогою ip route та tailscale status --json маршрутизатора. Звузьте рекламовані префікси. Вимкніть автоприйняття маршрутів там, де потрібно, і накладайте ACL на призначення підмережі.

4) «Підрядник все ще має доступ після відбору»

Симптоми: Користувача видалили з груп IdP, але його пристрій все ще підключається або має доступ.

Корінь: Пристрій залишається авторизованим; ACL тегів занадто широкі; або довгоживучий auth key зареєстрував вузол, не звʼязаний з ідентичністю підрядника.

Виправлення: Вимагайте затвердження/терміну дії пристроїв, регулярно чистіть список пристроїв і віддавайте перевагу привʼязаній до користувача ідентичності. Для машинних ключів обмежуйте скоуп і ротуйте їх. Зробіть «offboarding включає пристрої Tailscale» обовʼязковим.

5) «MagicDNS не працює на моєму ноуті, але працює на серверах»

Симптоми: dig не повертає імена tailnet; доступ по IP працює; поведінка різниться по ОС.

Корінь: Налаштування DNS клієнта переопрацьоване іншим VPN, локальним резолвером, captive portal або черговістю пріоритетів DNS в ОС.

Виправлення: Перевірте через dig і Інспектуйте налаштування DNS ОС. Вимкніть конфліктні VPN-DNS і стандартизуйте політику клієнтів. Якщо ви покладаєтесь на split DNS — тестуйте на кожній платформі, яку підтримуєте.

6) «Ми не можемо дістатися підмережі дата-центру з Tailscale»

Симптоми: Вузли tailnet можуть спілкуватися між собою, але не з 10.x/192.168.x позаду підмережного маршрутизатора.

Корінь: Маршрутизатор не форвардить (IP forwarding вимкнено), фаєрвол блокує, або маршрути не затверджені в адмін-інтерфейсі.

Виправлення: Увімкніть IP forwarding на маршрутизаторі, дозвольте форвард у фаєрволі і підтвердьте, що рекламовані маршрути затверджені, а клієнти їх приймають. Потім тестуйте traceroute і nc.

7) «Увімкнено exit node і тепер SaaS-логіни виглядають підозріло»

Симптоми: Гео-попередження, повторні виходи з сесій, сайти показують інший регіон; на одному вузлі — сплески трафіку.

Корінь: Користувачі несвідомо маршрутизують весь трафік через exit node, змінюючи egress IP і місцезнаходження.

Виправлення: Обмежте використання exit node певними групами. Навчіть користувачів, коли їх використовувати. Моніторте exit nodes. Розгляньте виділені «регіони egress», якщо потрібна відповідність вимогам.

Три невеликі корпоративні історії з реального життя

Міні-історія 1: Інцидент через хибне припущення

Середня SaaS-компанія впровадила Tailscale замість старого IPsec. План був простий: інженери підключаються з ноутів,
заходять на bastion і далі до внутрішніх сервісів. Хтось додав підмережний маршрутизатор, щоб зробити доступною стару мережу моніторингу.

Хибне припущення було тонким: вони вважали, що «advertise a subnet route» означає «тільки кілька людей зможуть її використовувати».
Насправді кожен клієнт приймав маршрути за замовчуванням, а ACL були написані широко («engineering може дістатися internal»),
бо це відповідало старій VPN-культурі.

Через тиждень інженер з особистого пристрою приєднався в tailnet, встановив інструмент для дебагу і випадково просканував мережу моніторингу.
Нічого зловмисного. Але алерти виглядали як розвідка. Security прокинувся. Менеджмент — теж. Всім було некомфортно.

Виправлення не було драматичним: звузили ACL до конкретних призначень і портів, вимагали підтвердження пристрою для нових вузлів,
і зробили прийняття підмереж явним лише для ролей, які його потребують. Реальний урок: накладна маршрутизація змінює, хто «бачить» мережі.
Якщо ви цього явно не задокументуєте, ви дізнаєтесь під час інцидент-ревью.

Міні-історія 2: Оптимізація, що обернулась проти

Команда IT вирішила стандартизувати віддалений доступ, прокидуючи весь інтернет-трафік через exit nodes «для моніторингу безпеки».
Вони розгорнули пару exit nodes на регіон і вимагали, щоб користувачі їх вмикали. На папері це давало централізовану видимість і стабільний egress.

Назад пішло в три акти. По-перше, витрати на трафік зросли і exit nodes стали гарячими точками. По-друге, інтерактивна робота уповільнилась для
інженерів, які тепер хеппінгували через вузол виходу і назад до хмарних сервісів в іншому регіоні. По-третє, рутинне оновлення ядра
плюс баг драйвера NIC спричинило втрату пакетів на одному exit node, що перетворилося на компанійний інцидент «інтернет не працює».

Інцидент був жорсткий, бо виглядав як усе: DNS, SaaS-аутейджі, «проблеми з Wi-Fi» — все підряд.
Основна проблема була в тому, що вони відновили центральну точку трафіку — саме те, чого Tailscale допомагає уникати.

Вони відкотилися, зробивши використання exit nodes опціональним і обмеженим для конкретних сценаріїв (публічний Wi-Fi, геообмежені ресурси, тестування відповідності).
Також додали моніторинг і запас потужності для тих exit nodes, що залишилися. «Оптимізація» виявилась зміною топології, а зміни топології мають наслідки.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Фінтех використовував Tailscale у хмарі і на он-прем. У них була сувора звичка: кожна зміна доступу до проду вимагала невеликого запиту на зміну,
а кожна зміна ACL — peer review, навіть якщо це «просто відкрити 443 для нового сервісу».

Під час інциденту on-call інженеру терміново потрібен був доступ до ноди зберігання для збору логів. Найшвидша дорога — додати широке ACL-виключення для групи on-call на всю підмережу зберігання. Це вирішило б проблему за хвилини.

Але команда дотрималась нудної практики: вузьке ACL-правило, обмежене одним тегом хоста і одним портом, плюс короткоживучий чек стану пристрою.
Також задокументували це в нотатках інциденту і запланували видалення. Доступ спрацював, інцидент просунувся, і нічого «зайвого» не залишилось відкритим.

Через кілька тижнів скомпрометований ноут підрядника потрапив у tailnet. Досяг злоумисника був обмежений.
Флот зберігання не був у зоні поширення, бо ACL були точними й перевіреними. Команда не святкувала.
Вони просто продовжили роботу. Ось як виглядає «правильно» в операціях: майже нудно і практично без пригод.

Контрольні списки / покроковий план

Покроково: розгортання Tailscale з думкою про продакшен

1. Визначте цілі доступу. Перелічіть сервіси і порти, які мають бути доступні, за ролями. Якщо ви не можете це перерахувати — ви не зможете це захистити.
2. Виберіть ідентичність і вимагайте MFA. Якщо є SSO — використовуйте його і вимагаєте MFA. Якщо ні — тримайте auth keys як секрети з управлінням життєвого циклу.
3. Увімкніть видимість пристроїв і затвердження. Вирішіть, чи нові пристрої автозатверджуються. Для продакшену — за замовчуванням вимагати затвердження.
4. Встановіть нівінги та теги. Люди в групах. Сервери в тегах. Ніяких винятків «бо так простіше».
5. Почніть з встановлення Tailscale на хостах, де це можливо. Підмережні маршрути — тимчасовий міст, не стиль життя.
6. Пишіть мінімальні ACL. Почніть з одного правила «admin → bastion:22» і розширюйте обережно.
7. Увімкніть MagicDNS свідомо. Тестуйте на всіх ОС, які підтримуєте. Документуйте, як працює split DNS, якщо використовуєте.
8. Визначте політику щодо exit nodes. Якщо дозволяєте — будуйте виділені вузли виходу і обмежуйте їх використання. Інакше — відключіть або заблокуйте політикою.
9. Збережіть break-glass доступ. Консольний доступ, cloud serial, iLO/iDRAC або еквівалент. Він знадобиться одного дня.
10. Інструментуйте і налаштуйте алерти. Слідкуйте за змінами у використанні DERP, навантаженням exit nodes і логами tailscaled на критичних вузлах.
11. Навчіть on-call за планом діагностики. Переконайтеся, що люди відрізняють помилку ACL від проблеми DNS чи привʼязки сервісу.
12. Проводьте квартальну чистку доступу. Очищайте старі пристрої, ротуйте ключі, переглядайте ACL і аудит маршрутів підмереж.

Чеклист: перед увімкненням підмережної маршрутизації

• Підтвердьте, що підмережа не перекривається з існуючими маршрутами клієнтів.
• Підтвердьте, що маршрутизатор має увімкнений IP forwarding і правила фаєрвола для форварду.
• Рекламуйте найменший префікс, що працює (уникайте /16, якщо вистачає /24).
• Обмежте доступ до підмережі ACL (не покладайтеся на «лише деякі люди її використовуватимуть»).
• Визначте, які клієнти приймають маршрути, і зробіть це явним.

Чеклист: перед увімкненням exit nodes

• Використовуйте виділені вузли виходу з патчами і моніторингом.
• Заблокуйте, хто може їх використовувати (тільки групи).
• Перевірте продуктивність і MTU-шлях, особливо для відеодзвінків і великих завантажень.
• Заплануйте вибір регіону і послідовність egress IP, якщо це важливо з точки зору відповідності.

Жарт №2: Найшвидший шлях «підвищити безпеку» — прокинути все через одну коробку — до того моменту, коли вона стане вашим новим хобі.

Питання й відповіді

Чи Tailscale — це «просто WireGuard»?

Під капотом він використовує WireGuard для data plane. Різниця — в control plane: ідентичність, розподіл ключів,
координація обходу NAT, ACL і додаткові фічі як MagicDNS і Tailscale SSH. Це те, що замінює ваші DIY-скрипти.

Чому я бачу «relay» у tailscale status?

Це значить, що зʼєднання не вдалося встановити напряму (зазвичай через NAT/фаєрвол/UDP), тому трафік йде через DERP.
Він все ще шифрує end-to-end, але затримки і пропускна здатність можуть страждати.

Чи можна використовувати Tailscale без встановлення на кожен сервер?

Так: використовуйте підмережний маршрутизатор. Але розумійте компроміс: ви втрачаєте ідентичність на рівні хостів і створюєте залежність від маршрутизації.
Це добре для legacy-мереж і міграцій. Для greenfield-серверів це не мій перший вибір.

У чому різниця між підмережною маршрутизацією та вузлом виходу?

Підмережна маршрутизація рекламує конкретні внутрішні префікси (наприклад 10.20.0.0/16) у tailnet.
Вузол виходу маршрутизує за замовчуванням маршрут клієнта (0.0.0.0/0) через вузол tailnet, впливаючи на загальний інтернет-трафік.

Чи варто дозволяти персональні пристрої в tailnet?

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

Як взаємодіють ACL і локальні фаєрволи на хості?

ACL контролюють, що Tailscale дозволяє на шарі накладки. Локальні фаєрволи контролюють, що ОС дозволяє.
Потрібні обидва. ACL зупиняє встановлення зʼєднання; локальний фаєрвол зупиняє несподіваний трафік навіть якщо ACL занадто щедрі.

Чи безпечно використовувати Tailscale SSH у продакшені?

Так, якщо ви ставитесь до нього як до системи привілейованого доступу: жорсткі політики, обережне впровадження і break-glass доступ.
Основний ризик — операційний: неправильна конфігурація, що закриє доступ — не криптографічна слабкість.

Яке найпоширеніше «вимикається» фальшиве сповіщення?

DNS. Або MagicDNS не розвʼязує, або split DNS не застосований, або інший VPN/клієнт перехопив налаштування резолвера.
Перевірте доступ по IP tailnet; якщо це працює — це розвʼязування імен, а не маршрутизація.

Як правильно вивести користувача з системи?

Видаліть користувача з груп IdP, деактивуйте його SSO і також перегляньте та видаліть його авторизовані пристрої з tailnet.
Якщо ви використовуєте auth keys для машин — ротуйте ключі за графіком і гарантовано, що ключі скоуповані так, щоб не реєструвати випадкові пристрої.

Чи означає використання DERP, що Tailscale може читати наш трафік?

Ні. DERP ретранслює зашифровані пакети; він не розшифровує їх.
Ваша продуктивність може змінитися, але вміст трафіку ретранслятор не бачить.

Висновок: наступні кроки, що не застаріють

Tailscale виправдовує репутацію «VPN без болю», коли ви ставитесь до нього як до продакшен-системи: явна ідентичність, явна політика
і явна маршрутизація. Більшість відмов не містичні. Вони базові: неправильний tailnet, неправильний ACL, неправильний маршрут, плутанина DNS, або сервіс привʼязаний до localhost.
Трюк — дебажити в правильному порядку й тримати blast radius малим.

Практичні наступні кроки:

• Прийміть швидкий план діагностики і навчіть йому on-call.
• Аудитуйте ACL на предмет мінімальних привілеїв і видаліть «тимчасові» широкі правила.
• Перепишіть інвентар підмереж і зробіть прийняття маршрутів явним; звужуйте префікси коли можливо.
• Якщо використовуєте exit nodes — ставте їх як критичну інфраструктуру: виділені хости, моніторинг і жорсткий доступ.
• Проводьте квартальну гігієну: пристрої, ключі, теги й поведінка DNS на різних платформах.

Тримайте це нудним. Нудно — це як ви спите.