Vymažete člena, zavriete stránku a o deň neskôr je to isté zariadenie späť. To nie je chyba konzoly. To sa stane, keď sa záznam vymaže, kým je zariadenie ešte online a stále žiada o pripojenie.

Dve operácie stoja vedľa seba a robia rôznu prácu. Jedna rozhoduje o prístupe, druhá len upratuje zoznam.

Začnite pri zázname, ktorý sa vracia

Otvorte sieť a pozrite sa na záznam, ktorý sa vrátil. Poznamenajte si jeho node ID, poslednú adresu a čas, kedy sa znova objavil. Porovnajte to so zariadením, ktoré ste chceli vyradiť. Zobrazované meno je to, čo niekto napísal, a adresa sa môže pri ďalšom pripojení zmeniť.

Node ID je stabilný identifikátor. ID siete pomenúva sieť, takže vám hovorí, ktorý zoznam čítate, a nič o tom, ktoré zariadenie v ňom je. Zapíšte oboje a potom porovnajte node ID so strojom, ktorý ste chceli vyradiť.

Ak toto porovnanie pomýlite, odstránite fungujúci stroj, kým ten nechcený ďalej žiada. Zoznam potom vyzerá jeden deň správne. To je dosť dlho na to, aby si to nikto nevšimol, a práve v tom je problém.

Zrušte skôr, než vymažete

Najprv zmeňte stav autorizácie postupom, ktorý kontrolér podporuje. Od tej chvíle sa pokus o pripojenie javí ako neautorizovaný, namiesto toho aby potichu obnovil prístup, a žiadosť je viditeľná, nie neviditeľná.

Mazanie prichádza potom, nikdy namiesto toho. Odstránením záznamu autorizovaného člena nezostane nič na zrušenie. Zariadenie sa spýta znova a kontrolér ho berie ako nové.

Pri stroji, ktorý ešte ovládate, je opustenie siete užitočnou súčasťou vyradenia. Nenahrádza rozhodnutie správcu o stratenom zariadení. Klient, ktorý už nie je pod vašou kontrolou, môže ignorovať všetko, čo mu bolo povedané.

Kde sídlia obe operácie

Na hostovanom kontroléri ponúka zoznam členov obe akcie a označuje ich dosť jasne na to, aby sa dali rozlíšiť. Na vlastnom kontroléri sa rovnaký rozdiel objavuje v API a v miestnej konfigurácii, a práve tam sa zmätok zvyčajne začína.

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

Tieto dva volania stačia na to, aby ukázali, či bol člen niekedy skutočne neautorizovaný. Záznam, ktorý sa stále vracia s authorized: true, nebol nikdy zrušený; bol len vymazaný.

Overte to na zdroji, nie v zozname

Uprataný zoznam členov nie je kontrola prístupu. Skúste zdroj, ktorý zariadenie používalo predtým, z toho zariadenia alebo zo stroja s jeho starou adresou, a potvrďte, že spojenie zlyhá. Potom potvrďte, že schválená náhrada stále funguje.

Zahrňte do tohto testu trasy a oprávnenia služieb. ZeroTier môže člena autorizovať a napriek tomu mu nedovoliť dostať sa na spravovanú trasu. Oprávnenie aplikácie môže zlyhať rovnako. Zo zoznamu členov vyzerajú oba prípady rovnako.

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

Pri vlastnom kontroléri udržujte konzistentnú zálohu jeho identity a konfigurácie. Obnova, ktorá sa vráti k staršiemu stavu, môže priniesť späť aj starú autorizáciu a zoznam členov bude vyzerať presne ako pred vyradením.

Vyradenie je hotové, keď stará identita na nič nedosiahne a záznam zmizne. Urobte to v tomto poradí a člen sa prestane vracať.

Súvisiace články