Чому клієнт Tailscale у Linux ігнорує оголошені маршрути підмереж

Таблиця 52 — це підказка: клієнт Tailscale у Linux встановлює оголошений маршрут підмережі лише після --accept-routes, а схвалення пристрою — окремі ворота.

Ви за ноутбуком із Linux, tailscale status перелічує інші машини, а NAS за адресою 10.80.0.25 досі вичерпує час. Tailnet здоровий, маршрутизатор підмережі в мережі, і ніщо у виводі клієнта не каже, чому LAN за ним недоступна. Розбір нижче рухається від цього симптому назовні: прапорець на цьому клієнті, потім оголошення на маршрутизаторі, потім схвалення, потім політика, і лише потім сам пункт призначення. Кожні ворота відмовляють з однаковим часом очікування, тому порядок важливіший за команди.

Що клієнт Linux відмовляється встановлювати

Клієнти Tailscale у Linux не приймають оголошені маршрути підмереж, якщо їх не попросити. Без цього налаштування клієнт приєднується до tailnet і досягає адрес вузлів, тоді як кожен префікс, який оголошує маршрутизатор, залишається невикористаним. Типове значення навмисне, і саме тому симптом виглядає як зламаний маршрутизатор, а не як локальне рішення.

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

Увімкніть приймання маршрутів для цієї машини

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

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale встановлює прийняті маршрути у власну таблицю в Linux, тому префікс, що з'явився в таблиці 52, — прямий доказ того, що цей клієнт установив оголошення. Якщо вашого діапазону немає в цій таблиці, зупиніться: проблема локальна, і жодна робота на маршрутизаторі її не змінить.

Старіші клієнти пропонують те саме налаштування як прапорець команди входу, тому sudo tailscale up --accept-routes — запасний варіант, коли tailscale set відсутній. Використовуйте його замість ручного редагування маршрутів, бо демон переписує власну таблицю, і ваша правка зникає при наступному підключенні. Перевірте версію, перш ніж копіювати команду зі старої статті.

Перевіряйте оголошення й схвалення окремо

На маршрутизаторі підмережі префікс потрібно оголосити, а ядро має пересилати пакети між інтерфейсами. Оголошення без пересилання дає схвалений маршрут, який тихо відкидає трафік, і це найпоширеніше незавершене налаштування.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

Порівняйте оголошений префікс з адресою, якої ви насправді намагаєтеся досягти, символ за символом. Маршрутизатор, що оголошує 10.70.0.0/24, нічого не каже про NAS за адресою 10.80.0.25, і невідповідність непомітна в будь-якому виводі стану, бо обидва числа виглядають однаково правдоподібно. Більшість повідомлень про зламаний маршрут закінчуються тут. Виправте оголошення, перш ніж чіпати щось нижче.

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

Спочатку перевірте приватну адресу, а не ім'я хоста

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

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

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

Одна локальна перевірка варта того, перш ніж звинувачувати tailnet. Коли ваша поточна LAN використовує той самий префікс, що й віддалена підмережа, ядро віддає перевагу безпосередньо підключеному маршруту, і трафік ніколи не покидає машину; так буває, коли дім і офіс обидва обрали 192.168.1.0/24.

Чому прапорець клієнта не є налаштуванням маршрутизатора

Це різні ролі з різними вимогами, і копіювання прапорця клієнта на маршрутизатор — це спосіб, яким робочий tailnet отримує петлю. Машині, що оголошує маршрути, потрібні пересилання, правила брандмауера, які дозволяють пересланий трафік, і рішення про те, які префікси вона оголошує. Ніщо з цього не випливає з --accept-routes.

Документація з маршрутизаторів підмереж застерігає не вмикати приймання маршрутів на резервних маршрутизаторах, які оголошують один префікс, бо резервний вузол може виштовхнути вже локальний трафік через активний. Якщо у вас пара HA, ставтеся до цього як до проєктного обмеження, а не виноски, і вирішіть, якому вузлу належить префікс, перш ніж схвалювати його на обох. На одному маршрутизаторі те саме попередження читається як нагадування, що приймання належить клієнтам, а не машині, яка оголошує. Запишіть, які ворота були зачинені.

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

Схожі статті