Smažete člena, zavřete stránku a za den je stejné zařízení zpět. To není chyba konzole. To se stává, když se záznam smaže, zatímco zařízení je ještě online a stále žádá o připojení.

Dvě operace stojí vedle sebe a dělají různou práci. Jedna rozhoduje o přístupu, druhá jen uklízí seznam.

Začněte u záznamu, který se vrací

Otevřete síť a podívejte se na záznam, který se vrátil. Poznamenejte si jeho node ID, poslední adresu a čas, kdy se znovu objevil. Porovnejte to se zařízením, které jste chtěli vyřadit. Zobrazované jméno je to, co někdo napsal, a adresa se může při dalším připojení změnit.

Node ID je stabilní identifikátor. ID sítě pojmenovává síť, takže vám říká, který seznam čtete, a nic o tom, které zařízení v něm je. Zapište obojí a potom porovnejte node ID se strojem, který jste chtěli vyřadit.

Spletete-li toto porovnání, odstraníte funkční stroj, zatímco ten nechtěný dál žádá. Seznam pak jeden den vypadá správně. To je dost dlouho na to, aby si toho nikdo nevšiml, a právě v tom je problém.

Zrušte autorizaci dřív, než smažete

Nejprve změňte stav autorizace postupem, který kontroler podporuje. Od té chvíle se pokus o připojení jeví jako neautorizovaný, místo aby tiše obnovil přístup, a žádost je viditelná, ne neviditelná.

Smazání přichází potom, nikdy místo toho. Odstraněním záznamu autorizovaného člena nezůstane nic ke zrušení. Zařízení se zeptá znovu a kontroler ho bere jako nové.

U stroje, který ještě ovládáte, je opuštění sítě užitečnou součástí vyřazení. Nenahrazuje rozhodnutí správce o ztraceném zařízení. Klient, který už neovládáte, může ignorovat, co se mu řeklo.

Kde obě operace sídlí

Na hostovaném kontroleru nabízí seznam členů obě akce a označuje je dost jasně na to, aby se daly rozlišit. Na vlastním kontroleru se stejný rozdíl objevuje v API a v místní konfiguraci, a právě tam obvykle začíná zmatek.

# 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"

Tyto dva požadavky stačí k tomu, abyste zjistili, zda byl člen někdy skutečně neautorizovaný. Záznam, který se stále vrací s authorized: true, nebyl nikdy zrušen; byl jen smazán.

Ověřte to na prostředku, ne v seznamu

Uklizený seznam členů není kontrola přístupu. Zkuste prostředek, který zařízení používalo dřív, z toho zařízení nebo ze stroje s jeho starou adresou, a potvrďte, že spojení selže. Potom potvrďte, že schválená náhrada stále funguje.

Zahrňte do toho testu i trasy a oprávnění služeb. ZeroTier může člena autorizovat a přesto mu znemožnit dosáhnout spravované trasy. Oprávnění aplikace může selhat stejně. Ze seznamu členů vypadají oba případy stejně.

zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5

U vlastního kontroleru udržujte konzistentní zálohu jeho identity a konfigurace. Obnova, která se vrátí k dřívějšímu stavu, může přinést zpět i starou autorizaci a seznam členů bude vypadat přesně jako před vyřazením.

Vyřazení je hotové, když stará identita na nic nedosáhne a záznam zmizí. Udělejte to v tomto pořadí a člen se přestane vracet.

Související články