Зошто одобрената рута до подмрежа во 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 за да работи една апликација е начинот на кој тесно барање станува широка дозвола што подоцна никој не се осмелува да ја отстрани.

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