Видалений учасник ZeroTier повертається: спершу відкличте авторизацію

Пристрій у мережі може знову попроситися до мережі, щойно його запис видалено. Відкличте авторизацію, а видалення після цього вважайте прибиранням списку.

Ви видаляєте учасника, закриваєте сторінку, а за день той самий пристрій знову тут. Це не помилка консолі. Так буває, коли запис видаляють, поки пристрій ще в мережі й досі просить приєднання.

Дві операції стоять поруч і роблять різну роботу. Одна вирішує доступ, інша лише прибирає список.

Почніть із запису, що повертається

Відкрийте мережу й подивіться на запис, що повернувся. Запишіть його node ID, останню адресу та час, коли він з'явився знову. Порівняйте це з пристроєм, який ви хотіли вивести з експлуатації. Показане ім'я — це те, що хтось ввів, а адреса може змінитися під час наступного приєднання.

Node ID — це стабільний ідентифікатор. 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

Для власного контролера тримайте узгоджену резервну копію його ідентичності та конфігурації. Відновлення, що відкочується до попереднього стану, може повернути й стару авторизацію, і список учасників виглядатиме точно так, як до виведення з експлуатації.

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

Схожі статті