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