Выдалены ўдзельнік ZeroTier вяртаецца: спачатку адклічце дазвол

Прылада ў сетцы можа зноў папрасіць далучыцца, як толькі яе запіс выдаляць. Спачатку адклічце дазвол, а выдаленне лічыце чысткай спісу.

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

Дзве аперацыі стаяць побач і робяць рознае. Адна вырашае доступ, другая толькі прыбірае спіс.

Пачніце з запісу, які вяртаецца

Адкрыйце сетку і паглядзіце на запіс, які вярнуўся. Запішыце яго node ID, апошні адрас і час, калі ён зноў з'явіўся. Параўнайце гэта з прыладай, якую вы збіраліся вывесці з эксплуатацыі. Імя для адлюстравання — гэта тое, што хтосьці ўвёў, а адрас можа змяніцца пры наступным далучэнні.

Node ID — гэта стабільны ідэнтыфікатар. Ідэнтыфікатар сеткі называе сетку, таму ён кажа, які спіс вы чытаеце, і нічога не кажа пра тое, якая прылада ў ім. Запішыце абодва, затым супастаўце node ID з машынай, якую вы збіраліся вывесці з эксплуатацыі.

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

Адклічце дазвол да выдалення

Спачатку змяніце стан дазволу праз працоўны працэс, які падтрымлівае кантролер. З гэтага моманту спроба далучэння выглядае як недазволеная, а не як ціхае аднаўленне доступу, і запыт бачны, а не нябачны.

Выдаленне ідзе пасля, ніколі замест. Калі выдаліць запіс удзельніка з дазволам, не застанецца нічога, што можна адклікаць. Прылада просіць зноў, і кантролер лічыць яе новай.

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

Дзе жывуць дзве аперацыі

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

# list members with authorization state
curl -s -H "X-ZT1-Auth: $TOKEN" \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member" | jq 'to_entries[] | {id: .key, authorized: .value.authorized}'

# deauthorize one member by node id, then confirm
curl -s -X POST -H "X-ZT1-Auth: $TOKEN" -d '{"authorized": false}' \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member/$NODE_ID"

Гэтых двух выклікаў дастаткова, каб паказаць, ці быў удзельнік калі-небудзь сапраўды без дазволу. Запіс, які ўвесь час вяртаецца з authorized: true, ніколі не адклікалі; яго проста выдалілі.

Правярайце па рэсурсе, а не па спісе

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

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

zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5

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

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

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