Избришан член на 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

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

Повлекувањето е завршено кога стариот идентитет не може да стигне до ништо и записот го нема. Направете го тоа по тој редослед и членот престанува да се враќа.

Поврзани статии