Один хост Tailscale недоступний: маршрутизатор підмережі чи вихідний вузол?

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

Почніть із цілі, яка не спрацювала

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

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

Дістаньтеся пристрою, який ніколи не запускає Tailscale

Маршрутизатор оголошує певні діапазони в tailnet, потім передає пакети між tailnet і приватним сегментом, тож пристроям у цьому сегменті не потрібен власний клієнт. Доступ до NAS в офісі з ноутбука вдома — саме цей випадок. Маршрутизатор — єдиний член tailnet на тому боці.

tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status

Оголошення — лише перша з трьох умов. Маршрут має бути схвалений для tailnet, клієнт має прийняти оголошені маршрути, і правило доступу має дозволяти з'єднання. Саме через цей ланцюг симптом так часто виглядає як працюючий маршрутизатор і недоступний NAS. Доступний маршрутизатор доводить, що тунель працює; він нічого не доводить про схвалення, прийняття клієнтом чи політику.

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

Виведіть публічний трафік через іншу машину

Вихідний вузол пропускає ваш загальний інтернет-трафік через себе, що найближче до схеми повного тунелю в інших VPN-продуктах. Йому теж потрібні три окремі згоди: пристрій оголошує роль, адміністратор її дозволяє, а клієнт її обирає. Приєднання до tailnet типово нічого не надсилає через іншого учасника.

tailscale up --advertise-exit-node
tailscale up --exit-node=100.101.102.103 --exit-node-allow-lan-access=false
tailscale status --json | grep -i exitnode

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

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

Прочитайте тристоронній поділ, коли відмовляє лише один хост

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

Якщо адреса працює, а ім'я ні, припиніть дивитися на маршрути. Приватний DNS налаштовується окремо, і ім'я, що розв'язується в неправильну адресу, відмовляє так само, як виглядає заблокований маршрут. Спершу перевірте адресу, потім ім'я, і два результати скажуть, який рівень відкривати.

Підтвердьте шлях, який, на вашу думку, ви збудували

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

ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55

Зіставте це з власним поданням tailnet, яке показує, чи партнер під'єднаний напряму чи через релей. Шлях через релей теж працює, і це пояснює скарги на затримку, що не мають нічого спільного з маршрутом, який ви налагоджували. документація маршрутизатора підмережі описує крок схвалення, якщо він незнайомий. Потім запишіть, яка конструкція покриває яку ціль у вашій мережі, бо наступна людина, що додає майданчик, поставить те саме питання.