Ištrintas „ZeroTier“ narys grįžta: pirmiausia atšaukite leidimą

Ištrinate narį, uždarote puslapį, o po dienos tas pats įrenginys vėl čia. Tai ne konsolės klaida. Taip nutinka, kai įrašas ištrinamas įrenginiui dar esant prisijungusiam ir vis dar prašant prisijungti.

Dvi operacijos yra greta ir atlieka skirtingus darbus. Viena sprendžia apie prieigą, kita tik sutvarko sąrašą.

Pradėkite nuo įrašo, kuris grįžta

Atidarykite tinklą ir pažiūrėkite į grįžusį įrašą. Užsirašykite jo node ID, paskutinį adresą ir laiką, kada jis vėl pasirodė. Palyginkite tai su įrenginiu, kurį ketinote išjungti. Rodomas vardas yra tai, ką kažkas įvedė, o adresas gali pasikeisti per kitą prisijungimą.

Node ID yra pastovus identifikatorius. Tinklo ID suteikia tinklui pavadinimą, todėl jis pasako, kurį sąrašą skaitote, ir nieko apie tai, kuris įrenginys jame yra. Užsirašykite abu, tada sugretinkite node ID su mašina, kurią ketinote išjungti.

Jei šį palyginimą atliksite neteisingai, pašalinsite veikiančią mašiną, o nepageidaujamas įrenginys vis prašys. Tada sąrašas dieną atrodo teisingai. To pakanka, kad niekas nepastebėtų, ir būtent tai yra problema.

Atšaukite prieš ištrindami

Pirmiausia pakeiskite leidimo būseną per valdiklio palaikomą darbo eigą. Nuo tos akimirkos prisijungimo bandymas rodomas kaip neleistinas, o ne tyliai atkuriantis prieigą, ir užklausa yra matoma, o ne nematoma.

Trynimas ateina po to, niekada vietoj jo. Pašalinus leidimą turinčio nario įrašą, nebelieka ko atšaukti. Įrenginys vėl klausia, o valdiklis traktuoja jį kaip naują.

Mašinai, kurią dar valdote, tinklo palikimas yra naudinga išjungimo dalis. Tai nepakeičia administratoriaus sprendimo dėl pamesto įrenginio. Klientas, kurio nebevaldote, gali nepaisyti visko, kas jam buvo pasakyta.

Kur yra dvi operacijos

Prižiūrimame valdiklyje narių sąrašas siūlo abu veiksmus ir žymi juos pakankamai aiškiai, kad būtų galima atskirti. Savarankiškai prižiūrimame valdiklyje tas pats skirtumas matomas API ir vietinėje konfigūracijoje, ir dažniausiai nuo to prasideda painiava.

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

Šių dviejų užklausų pakanka parodyti, ar narys kada nors tikrai buvo neleistinas. Įrašas, kuris nuolat grįžta su authorized: true reikšme, niekada nebuvo atšauktas; jis buvo tik ištrintas.

Patikrinkite iš ištekliaus, o ne iš sąrašo

Tvarkingas narių sąrašas nėra prieigos patikra. Išbandykite išteklių, kurį įrenginys naudojo anksčiau, iš to įrenginio arba iš mašinos, turinčios jo seną adresą, ir patvirtinkite, kad ryšys nepavyksta. Tada patvirtinkite, kad patvirtintas pakaitalas vis dar veikia.

Įtraukite maršrutus ir paslaugų leidimus į tą testą. „ZeroTier“ gali leisti nariui ir vis tiek neleisti jam pasiekti valdomo maršruto. Programos leidimas gali nepavykti taip pat. Abu iš narių sąrašo atrodo vienodai.

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

Savarankiškai prižiūrimam valdikliui laikykite nuoseklią jo tapatybės ir konfigūracijos atsarginę kopiją. Atkūrimas, kuris grąžina į ankstesnę būseną, gali sugrąžinti ir seną leidimą, o narių sąrašas atrodys lygiai taip pat kaip prieš išjungimą.

Išjungimas baigtas, kai sena tapatybė nieko nepasiekia ir įrašo nebėra. Atlikite tai tokia tvarka ir narys nustos grįžti.