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

За обикновен клиент последователността завършва с теста на приложението, който се провали в началото. За рутера прегледайте препращането, обявяването, одобрението и защитната стена в този ред, защото първото липсващо дава точно изтичането, с което започнахте.

Подобни статии