Ahli ZeroTier yang dipadam kembali muncul: batalkan kebenaran dahulu

Anda memadam ahli, menutup halaman, dan sehari kemudian peranti yang sama kembali. Itu bukan pepijat dalam konsol. Itulah yang berlaku apabila rekod dipadam semasa peranti masih dalam talian dan masih meminta untuk menyertai.

Dua operasi terletak bersebelahan dan melakukan kerja yang berbeza. Satu menentukan akses, yang satu lagi hanya mengemas senarai.

Mulakan dengan rekod yang muncul semula

Buka rangkaian dan lihat entri yang kembali. Catat node ID-nya, alamat terakhirnya dan masa ia muncul semula. Bandingkan dengan peranti yang anda mahu nyahaktifkan. Nama paparan ialah apa sahaja yang seseorang taip, dan alamat boleh berubah pada penyertaan seterusnya.

Node ID ialah pengecam yang stabil. ID rangkaian menamakan rangkaian, jadi ia memberitahu senarai mana yang anda baca dan tidak memberitahu peranti mana yang ada di dalamnya. Catat kedua-duanya, kemudian padankan node ID dengan mesin yang anda mahu nyahaktifkan.

Jika perbandingan itu silap, anda akan membuang mesin yang berfungsi sementara peranti yang tidak dikehendaki terus meminta. Senarai kemudian kelihatan betul selama sehari. Itu cukup lama sehingga tiada siapa perasan, dan itulah masalahnya.

Batalkan sebelum anda memadam

Tukar dahulu keadaan kebenaran melalui aliran kerja yang disokong oleh pengawal. Dari saat itu, cubaan menyertai muncul sebagai tidak dibenarkan dan bukannya memulihkan akses secara senyap, dan permintaan itu kelihatan dan bukan tidak kelihatan.

Pemadaman datang selepas itu, tidak pernah sebagai gantinya. Membuang rekod ahli yang dibenarkan tidak meninggalkan apa-apa untuk dibatalkan. Peranti bertanya lagi, dan pengawal menganggapnya sebagai baharu.

Bagi mesin yang masih anda kawal, meninggalkan rangkaian ialah bahagian berguna dalam nyahaktifan. Ia bukan pengganti keputusan pentadbir tentang peranti yang hilang. Klien yang tidak lagi anda kawal boleh mengabaikan apa sahaja yang dikatakan kepadanya.

Di mana kedua-dua operasi berada

Pada pengawal yang dihoskan, senarai ahli menawarkan kedua-dua tindakan dan melabelnya cukup jelas untuk dibezakan. Pada pengawal yang anda hos sendiri, perbezaan yang sama muncul dalam API dan dalam konfigurasi setempat, dan dari situlah kekeliruan biasanya bermula.

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

Dua panggilan itu cukup untuk menunjukkan sama ada ahli itu pernah benar-benar tidak dibenarkan. Rekod yang terus kembali dengan authorized: true tidak pernah dibatalkan; ia hanya dipadam.

Sahkan daripada sumber, bukan senarai

Senarai ahli yang kemas bukan pemeriksaan akses. Cuba sumber yang digunakan peranti sebelum ini, dari peranti itu atau dari mesin yang menyimpan alamat lamanya, dan sahkan sambungan gagal. Kemudian sahkan pengganti yang diluluskan masih berfungsi.

Sertakan laluan dan kebenaran perkhidmatan dalam ujian itu. ZeroTier boleh membenarkan ahli dan masih membiarkannya tidak dapat mencapai laluan terurus. Kebenaran aplikasi boleh gagal dengan cara yang sama. Kedua-duanya kelihatan serupa dari senarai ahli.

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

Bagi pengawal yang anda hos sendiri, simpan sandaran yang konsisten bagi identiti dan konfigurasinya. Pemulihan yang kembali ke keadaan lebih awal boleh membawa kebenaran lama kembali bersamanya, dan senarai ahli akan kelihatan sama seperti sebelum nyahaktifan.

Nyahaktifan selesai apabila identiti lama tidak dapat mencapai apa-apa dan rekodnya sudah tiada. Lakukan dalam urutan itu dan ahli itu berhenti kembali.