Защо одобрен маршрут към подмрежа в Tailscale все още завършва с изтичане на времето

Одобрението в администраторската конзола изглежда като последната стъпка, но не е. Първо приложението изтича по време и едва след това откривате, че рутерът е онлайн и маршрутът е одобрен. Одобрението е стъпка на разпространение, а не разрешение и не гаранция за препращане. Четири етапа трябва да се подредят, преди пакет да стигне до хост зад рутер за подмрежа, и всеки от тях може да мине, докато следващият се проваля. Минавайте ги по ред и спрете на първия етап, който не се издържа.

Четири етапа, един провал

Рутерът обявява префикса, tailnet одобрява това обявление, клиентът приема получения маршрут, а политиката за достъп разрешава конкретната връзка. Това са четири отделни решения, взети от три различни компонента. Затова одобреният маршрут казва само, че мрежата вече е част от таблицата за маршрутизация на tailnet.

Четвъртият етап е този, който най-често се пропуска, защото първите три дават видимо състояние. Разрешението, което покрива собствения адрес на рутера в tailnet, не покрива автоматично частна подмрежа зад него. Това са различни дестинации и политиката се оценява за всяка дестинация поотделно.

В Linux третият етап има и настройка по подразбиране, която изненадва хората: приемането на маршрути към подмрежи е по избор. Няколко GUI клиента приемат обявените маршрути по подразбиране, така че в смесен парк една машина може да се проваля, докато останалите работят.

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

Ако целта е бил изход към интернет, а не частна подмрежа, правилният компонент е изходен възел, а не рутер за подмрежа, и политиката и маршрутизацията се различават съответно. Проверете това решение, преди да разширявате разрешение. Изходният възел променя маршрута по подразбиране; рутерът за подмрежа само обявява префикс.