Избрисан 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

За самостално хостован контролер држите доследну сигурносну копију његовог идентитета и конфигурације. Враћање на раније стање може са собом вратити стару ауторизацију, а листа чланова ће изгледати тачно као пре повлачења.

Повлачење је завршено када стари идентитет не може достићи ништа и запис је нестао. Урадите то тим редом и члан престаје да се враћа.

Повезани чланци