Чаму ўзгоднены маршрут падсеткі Tailscale ўсё яшчэ сканчаецца тайм-аўтам

Узгадненне ў адміністрацыйнай кансолі выглядае як апошні крок, але гэта не так. Спачатку сканчаецца тайм-аўт праграмы, і толькі потым вы бачыце маршрутызатар у сетцы і маршрут узгоджаным. Узгадненне — гэта крок размеркавання, а не дазвол і не гарантыя перасылкі. Чатыры этапы павінны супасці, перш чым пакет дасягне хоста за маршрутызатарам падсеткі, і кожны можа прайсці, пакуль наступны зрываецца. Праходзьце іх па парадку і спыніцеся на першым этапе, які не вытрымлівае.

Чатыры этапы, адна няўдача

Маршрутызатар аб’яўляе прэфікс, tailnet ухваляе гэтае аб’яўленне, кліент прымае атрыманы маршрут, а палітыка доступу дазваляе пэўнае злучэнне. Гэта чатыры асобныя рашэнні, якія прымаюць тры розныя кампаненты. Таму ўзгоднены маршрут кажа толькі пра тое, што сетка цяпер стала часткай табліцы маршрутызацыі tailnet.

Чацвёрты этап — той, які часцей за ўсё прапускаюць, бо першыя тры даюць бачны стан. Дазвол, які пакрывае ўласны адрас маршрутызатара ў tailnet, не пакрывае аўтаматычна прыватную падсетку за ім. Гэта розныя пункты прызначэння, і палітыка ацэньваецца для кожнага пункта прызначэння асобна.

У Linux трэці этап таксама мае прадвызначаныя паводзіны, якія здзіўляюць людзей: прыём маршрутаў падсетак уключаецца ўручную. Некалькі кліентаў з графічным інтэрфейсам прымаюць аб’яўленыя маршруты па прадвызначэнні, таму ў змяшаным парку адна машына можа падаць, пакуль астатнія працуюць.

Праверце наладу на машыне, якая падае, а не выказвайце здагадку пра платформу. Маршрут ніколі не быў тым, чаго не хапала на працоўных машынах, таму дайце ім даказаць, што бок 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, каб працавала адна праграма, — гэта шлях, якім вузкі запыт ператвараецца ў шырокі дазвол, які потым ніхто не адважваецца выдаліць.

Калі мэтай быў выхад у інтэрнэт, а не прыватная падсетка, правільны кампанент — гэта вузлавы пункт выхаду, а не маршрутызатар падсеткі, і палітыка з маршрутызацыяй адпаведна адрозніваюцца. Праверце гэта рашэнне, перш чым пашыраць дазвол. Вузлавы пункт выхаду змяняе прадвызначаны маршрут; маршрутызатар падсеткі толькі аб’яўляе прэфікс.