Чому схвалений маршрут до підмережі в Tailscale усе одно завершується тайм-аутом

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

Чотири етапи, один збій

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

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

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

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

Перевірте маршрут там, де працює клієнт

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

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

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

Щоб приймати маршрути в Linux, перепідключіться з прапорцем, а не припускайте, що він установлений: tailscale up --accept-routes. Клієнт, підключений з іншими прапорцями, зберігає їх, доки їх не змінять, тому перевірте поточне налаштування, перш ніж додавати ще одне. Повторний запуск першої команди після зміни має показати маршрут у таблиці.

Доведіть пересилання та зворотний шлях

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

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

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

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

Прочитайте правило доступу до ресурсу

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

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

Вивід стану визначає власні адреси клієнта та вузли, які він бачить, і з цим має збігатися селектор джерела політики. tailscale ping доводить шлях tailnet до самого маршрутизатора підмережі; він розв’язує імена вузлів і адреси tailnet, а не хости всередині оголошеної підмережі. Третя команда надсилає звичайний ехо-запит ICMP через маршрут до підмережі, тому її результат описує призначення, а не маршрутизатор. Відмова на рівні tailnet зазвичай повертається як відмова, тоді як пакет, що виходить і ніколи не повертається, завершується тайм-аутом.

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

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