Tailscale: subnet router, споделяне и ключове

01Какво ще научиш

• Как един Linux възел става subnet router: пренасочване на пакети, реклама на маршрут, одобрение и правило за достъп.
• Защо споделена машина от чужд акаунт не получава твоите маршрути — и как се заобикаля с релей.
• Какво да направиш, ако ключ изтече навън, и как да въртиш ключовете, без да губиш мрежата.
• Защо за нови правила се ползват grants, а не ACL.

02Преди да започнеш

• Акаунт в Tailscale с права да одобряваш маршрути и да променяш политиката за достъп (🌐 глобален услуга).
• Linux машина, която вече е в мрежата ти и стои във вътрешния LAN, който искаш да достигнеш — това ще е рутерът.
• Знаеш подмрежата на LAN-а (в примерите: <lan-subnet>) и има поне едно устройство в нея без Tailscale клиент (принтер, NAS, камера).
• Достъп до sudo на рутера и до административната конзола.

03Стъпки

1. Subnet router — мост към устройства без клиент

   ℹ️

   Основата: как се адресират възлите

   Всеки възел получава стабилен частен адрес от обхвата 100.64.0.0/10 (CGNAT, RFC 6598), който не се сменя, когато машината смени мрежата. Трафикът е директен и криптиран (WireGuard); през релейните сървъри на Tailscale (DERP) минава само когато NAT не позволява пряка връзка. В нашите проби устройство без Tailscale клиент стигаше услуги в мрежата по HTTP през subnet рутер, макар ping да не минаваше ⚠️ наше наблюдение.

   Не всяко устройство може да пусне Tailscale. Subnet рутерът е обикновен възел от мрежата ти, който рекламира LAN подмрежа, така че останалите възли да стигат до устройствата в нея. Нужни са три неща, и трите са отделни: пренасочване на пакети в ядрото, одобрен маршрут и правило, което разрешава трафика.

   bash · на рутеракопирай

   # 1) пренасочване на пакети (ако съществува /etc/sysctl.d)
   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
   # 2) рекламирай маршрута (замени с твоята подмрежа)
   sudo tailscale set --advertise-routes=<lan-subnet>

   След това в конзолата: Machines → рутерът → Subnets → Edit, отбележи маршрута и запази (не е нужно, ако си настроил autoApprovers в политиката). Накрая добави правило за достъп (стъпка 4). На Linux клиентите маршрутите се ползват само с включена опция:

   bash · на Linux клиентакопирай

   sudo tailscale set --accept-routes

   ⚠️

   Одобрението не е правило за достъп

   Одобрението вкарва маршрута в таблиците на клиентите; правилото решава кой какво може да праща. Липсва ли едното, пакетите не минават. Подмрежата е със SNAT по подразбиране — устройствата зад рутера виждат него като източник на трафика.
   ℹ️

   Ако клиентът има същата подмрежа

   Когато собственият LAN на клиента е със същия адресен обхват, локалната мрежа печели и маршрутът се чупи. В нашите проби помогна по-тесен маршрут (/32) само за целевото устройство; документацията потвърждава, че при припокриване се избира най-специфичният префикс, но самата ситуация с локален сблъсък ⚠️ не е описана там — провери я в своя случай.
   bash · на Linux клиента · /32 маршрут при сблъсъккопирай

   # само за целевото устройство; не оцелява рестарт — направи го трайно (напр. systemd услуга)
   sudo ip route add <адрес-на-целта>/32 dev tailscale0

   ⚠️

   Единична точка на отказ

   Ако един възел е и subnet router, и exit node, и connector, неговият отказ къса всичко през него. Планирай втори рутер (високата достъпност е описана в документацията) — а при два рутера със същите маршрути не включвай --accept-routes на резервния.

2. Споделяне между акаунти — и границата му

   Можеш да дадеш достъп до една машина на потребител от друга мрежа, без да я излагаш в интернет. Споделената машина е карантинирана: приема входящи връзки, но не започва свои. Споделянето премахва информацията за етикети, групи и подмрежи от мрежата на получателя, а машината се достига по пълното си MagicDNS име или по адрес.

   ⛔

   Споделена машина не получава твоите маршрути

   Нито правило за достъп, нито по-тесен маршрут не променя това: споделените машини не носят подмрежи между мрежите. Ако машина от чужд акаунт трябва да достигне устройство във твоя LAN, не очаквай subnet маршрут при нея.

   Заобиколно решение (наш модел): релей. Възел А в твоята мрежа вижда и споделената машина, и устройството в LAN-а. Той вика споделената машина (например по SSH, скрипт със статистика), чете резултата и го публикува към устройството или услугата в LAN-а. Така чуждата машина никога не се нуждае от твоите маршрути.

   Роля	Къде е	Какво прави
   Споделена машина	чужд акаунт	само отговаря на заявки
   Релей (възел А)	твоята мрежа	вика, чете, публикува
   Услуга в LAN	зад subnet router	получава резултата

   ⚠️

   Tailscale SSH на чужда машина

   На машина от чужд акаунт дръж Tailscale SSH изключен (tailscale set --ssh=false) и ползвай обикновения sshd — достъпът до нея се решава от политиката на чуждата мрежа, не от твоята.

3. Ключове: изтичане, срок и ротация

   Има два вида ключове и те се бъркат лесно. Auth ключът регистрира нов възел без браузър; node ключът е това, с което възелът се представя в мрежата и по подразбиране изтича на 180 дни.

   Ключ	Срок	На какво вни­маваш
   Auth, ед­но­кратен	1–90 дни (по подраз­биране 90)	Tailscale го отменя след употреба
   Auth, мно­го­кратен	1–90 дни	Опасен, ако изтече — пази го в хранилище за тайни
   Node ключ	180 дни по подраз­биране	Изтече ли, възелът изглежда „офлайн“, макар да работи локално

   🔑

   Ако auth ключ е изтекъл навън

   1) Отмени го в конзолата (Settings → Keys → Revoke). 2) Отмяната не деавторизира вече регистрираните с него възли — изтрий ги от Machines, ако не са твои. 3) Издай нов ключ — с етикет, с най-краткия работещ срок; за краткотрайни задачи отбележи „Ephemeral“. Никога не го слагай в хранилище с код, чат или снимка на екран.
   bash · регистрация с ключкопирай

   # ключът различава главни и малки букви; подай го през променлива, не го пиши в историята
   sudo tailscale up --auth-key="$TS_AUTHKEY"

   ⚠️

   Постоянен възел, който изглежда „офлайн“

   Ако възел, който винаги е включен, е „офлайн“ в конзолата, а локално състоянието му е здраво, първо подозирай изтекъл node ключ, не мрежата. Поправка: нова автентикация или изключване на срока за този възел (Machines → възелът → ключов срок). Устройствата с етикет имат изключен срок по подразбиране; телефони и лаптопи оставяй със срока — така изгубено устройство отпада само. В нашата проба рестартът не помогна ⚠️ не е потвърдено в документацията. Изтече ли ключът на connector (subnet router, exit node), маршрутите му остават, но са недостижими — документацията го нарича „fail close“.

4. Правила за достъп: ACL или grants

   И двете са отказ по подразбиране и живеят в политиката на мрежата. Tailscale препоръчва grants за всички нови правила: те дават всичко от ACL и повече; ACL продължават да работят и няма да бъдат премахнати, но не получават нови възможности.

   JSON · политика · едно и също правилокопирай

   // grants (препоръчано) — групата може порт 443 към подмрежата
   {"grants":[{"src":["group:<група>"],"dst":["<lan-subnet>"],"ip":["443"]}]}
   
   // ACL (първото поколение) — същото
   {"acls":[{"action":"accept","src":["group:<група>"],"dst":["<lan-subnet>:443"]}]}

   ℹ️

   Споделени потребители

   За хората, поканени в мрежата ти, има специална група autogroup:shared — можеш да ги ограничиш (например само портове 80 и 443), без да знаеш имейлите им. Внимавай с "src": ["*"]: включва и поканените.

04Проверка

05Какво следва

06Източници

1. Tailscale: Subnet routers — IP forwarding, tailscale set --advertise-routes, одобрение, --accept-routes, SNAT, fail close.
2. Tailscale: Share your machines with other users — карантина, премахване на подмрежи и етикети, autogroup:shared.
3. Tailscale: Auth keys — еднократни и многократни, срок 1–90 дни, ephemeral, с етикет, отмяна, node ключ 180 дни.
4. Tailscale: ACLs — grants като препоръчан синтаксис, ACL остават.
5. Tailscale: Grants — синтаксис на grants.
6. Tailscale: IP addresses — обхватът 100.64.0.0/10 (CGNAT) и стабилният адрес на възела.
7. Собствени полеви бележки на КАГАМИ (релей модел, обобщен). Проверка на командите: 01.10.2026.