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

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