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

За самостоятелно хостван контролер поддържайте последователно резервно копие на самоличността и конфигурацията му. Възстановяване, което се връща към по-ранно състояние, може да върне и старо разрешение, и списъкът с членове ще изглежда точно както преди извеждането от употреба.

Извеждането от употреба е завършено, когато старата самоличност не може да достигне нищо и записът е изчезнал. Направете това в този ред и членът ще спре да се връща.

Подобни статии