A törölt ZeroTier-tag visszatér: előbb vonja vissza az engedélyezést
Egy online eszköz azonnal újra csatlakozást kérhet, amint a rekordját eltávolítják. Előbb vonja vissza az engedélyezést, a törlést pedig utána tekintse a lista rendbetételének.
Törli a tagot, bezárja az oldalt, és egy nappal később ugyanaz az eszköz újra itt van. Ez nem hiba a konzolban. Ez akkor történik, amikor egy rekordot törölnek, miközben az eszköz még online, és még mindig csatlakozást kér.
Két művelet él egymás mellett, és különböző munkát végez. Az egyik a hozzáférést dönti el, a másik csak rendezi a listát.
Kezdje a visszatérő rekordnál
Nyissa meg a hálózatot, és nézze meg a visszatért bejegyzést. Jegyezze fel a node ID-jét, az utolsó címét és azt az időpontot, amikor újra megjelent. Hasonlítsa össze azzal az eszközzel, amelyet ki akart vonni a használatból. A megjelenített név az, amit valaki beírt, a cím pedig a következő csatlakozáskor megváltozhat.
A node ID a stabil azonosító. A hálózati ID nevet ad a hálózatnak, tehát megmondja, melyik listát olvassa, és semmit arról, melyik eszköz van benne. Jegyezze fel mindkettőt, majd egyeztesse a node ID-t azzal a géppel, amelyet ki akart vonni a használatból.
Ha elrontja ezt az összehasonlítást, eltávolít egy működő gépet, miközben a nem kívánt tovább kér. A lista ekkor egy napig helyesnek látszik. Ez elég hosszú ahhoz, hogy senki ne vegye észre, és pontosan ez a probléma.
A törlés előtt vonja vissza
Először a vezérlő által támogatott munkafolyamaton keresztül változtassa meg az engedélyezés állapotát. Ettől kezdve a csatlakozási kísérlet nem engedélyezettként jelenik meg, ahelyett hogy csendben helyreállítaná a hozzáférést, és a kérés látható lesz, nem láthatatlan.
A törlés utána jön, soha nem helyette. Egy engedélyezett tag rekordjának eltávolítása nem hagy semmit visszavonni. Az eszköz újra kér, és a vezérlő újként kezeli.
Egy gépnél, amelyet még irányít, a hálózat elhagyása hasznos része a kivonásnak. Ez nem helyettesíti az adminisztrátor döntését egy elveszett eszközről. Egy kliens, amelyet már nem irányít, figyelmen kívül hagyhatja, amit mondtak neki.
Hol él a két művelet
Egy hosztolt vezérlőn a taglista mindkét műveletet kínálja, és elég egyértelműen címkézi őket ahhoz, hogy megkülönböztethetők legyenek. Egy saját hosztolású vezérlőn ugyanez a különbség az API-ban és a helyi konfigurációban jelenik meg, és a zavar általában ott kezdődik.
# 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"
Ez a két hívás elég annak megmutatására, hogy a tag valaha valóban engedély nélküli volt-e. Egy rekord, amely újra meg újra visszatér authorized: true értékkel, soha nem lett visszavonva; csak törölték.
Az erőforrásnál ellenőrizze, ne a listánál
A rendezett taglista nem hozzáférés-ellenőrzés. Próbálja ki azt az erőforrást, amelyet az eszköz korábban használt, arról az eszközről vagy egy olyan gépről, amelyen a régi címe van, és erősítse meg, hogy a kapcsolat meghiúsul. Ezután erősítse meg, hogy egy jóváhagyott csere továbbra is működik.
Vonja be a tesztbe az útvonalakat és a szolgáltatási engedélyeket. A ZeroTier engedélyezhet egy tagot, és mégis megakadályozhatja, hogy elérjen egy felügyelt útvonalat. Egy alkalmazásengedély ugyanígy meghiúsulhat. A taglistáról mindkettő azonosnak látszik.
zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5
Saját hosztolású vezérlőnél tartson következetes biztonsági mentést az identitásáról és a konfigurációjáról. Egy korábbi állapotra visszaálló helyreállítás magával hozhat egy régi engedélyezést, és a taglista pontosan úgy fog kinézni, mint a kivonás előtt.
A kivonás akkor fejeződik be, amikor a régi identitás semmit sem ér el, és a rekord eltűnt. Ebben a sorrendben tegye, és a tag abbahagyja a visszatérést.