Зошто Linux Tailscale клиентот ги игнорира објавените маршрути за подмрежи

Табела 52 е знакот: Linux Tailscale клиентот инсталира објавен маршрут за подмрежа само по --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 добива јамка. Машина што објавува маршрути бара пренесување, firewall правила што го дозволуваат пренесениот сообраќај и одлука кои префикси ги објавува. Ништо од тоа не е подразбрано од --accept-routes.

Документацијата за рутери за подмрежи предупредува да не го вклучувате прифаќањето маршрути на резервни рутери што објавуваат еден префикс, бидејќи резервен јазол може да го исфрли сообраќајот што е веќе локален преку активниот. Ако имате HA пар, третирајте го тоа како проектно ограничување, а не како фуснота, и одлучете кој јазол го поседува префиксот пред да го одобрите на двата. На еден рутер истото предупредување се чита како потсетник дека прифаќањето им припаѓа на клиентите, а не на машината што објавува. Запишете која порта била затворена.

За обичен клиент редоследот завршува со тестот на апликацијата што не успеа на почетокот. За рутерот, прегледајте пренесување, објавување, одобрување и firewall по тој редослед, бидејќи првото што недостасува го создава точно тоа истекување со кое почнавте.

Поврзани статии