Удалённый участник 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

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

Вывод из эксплуатации завершён, когда старая идентичность ничего не может достичь, а запись исчезла. Сделайте это в таком порядке, и участник перестанет возвращаться.

Похожие статьи