Чаму кліент Tailscale у Linux ігнаруе абвешчаныя маршруты падсетак

Табліца 52 — гэта падказка: кліент Tailscale у Linux усталёўвае абвешчаны маршрут падсеткі толькі пасля --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 набывае пятлю. Машыне, якая абвяшчае маршруты, патрэбна перасылка, правілы фаеруола, што дазваляюць перасланы трафік, і рашэнне, якія прэфіксы яна абвяшчае. Нішто з гэтага не прадугледжана --accept-routes.

Дакументацыя па маршрутызатарах падсетак папярэджвае супраць уключэння прыёму маршрутаў на рэзервовых маршрутызатарах, якія абвяшчаюць адзін прэфікс, бо рэзервовы вузел можа выштурхнуць ужо лакальны трафік праз актыўны. Калі ў вас пара HA, стаўцеся да гэтага як да абмежавання праектавання, а не вынаскі, і вырашыце, які вузел валодае прэфіксам, перш чым ухваляць яго на абодвух. На адзіным маршрутызатары тое ж папярэджанне чытаецца як напамін, што прыём належыць кліентам, а не машыне, якая робіць абвяшчэнне. Запішыце, якая брама была зачынена.

Для звычайнага кліента паслядоўнасць сканчаецца праграмным тэстам, які праваліўся ў пачатку. Для маршрутызатара прагледзьце перасылку, абвяшчэнне, зацвярджэнне і фаеруол у гэтым парадку, бо першы адсутны дае менавіта той тайм-аўт, з якога вы пачалі.

Падобныя артыкулы