Почему клиент 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, относитесь к этому как к проектному ограничению, а не сноске, и решите, какому узлу принадлежит префикс, прежде чем одобрять его на обоих. На одном маршрутизаторе то же предупреждение читается как напоминание, что приём принадлежит клиентам, а не машине, которая объявляет. Запишите, какие ворота были закрыты.

Для обычного клиента последовательность заканчивается тестом приложения, который не прошёл в начале. Для маршрутизатора проверьте пересылку, объявление, одобрение и брандмауэр в этом порядке, потому что первый отсутствующий даёт ровно тот тайм-аут, с которого вы начали.

Похожие статьи