Anggota ZeroTier yang dihapus kembali muncul: cabut otorisasinya dulu

Anda menghapus anggotanya, menutup halaman, dan sehari kemudian perangkat yang sama kembali. Itu bukan bug di konsol. Itulah yang terjadi ketika sebuah catatan dihapus sementara perangkat masih online dan masih meminta bergabung.

Dua operasi berdampingan dan mengerjakan hal berbeda. Satu menentukan akses, yang lain hanya merapikan daftar.

Mulai dari catatan yang muncul kembali

Buka jaringan dan lihat entri yang kembali. Catat node ID-nya, alamat terakhirnya, dan waktu ia muncul lagi. Bandingkan dengan perangkat yang ingin Anda pensiunkan. Nama tampilan adalah apa pun yang diketik seseorang, dan alamatnya bisa berubah pada penggabungan berikutnya.

Node ID adalah pengenal yang stabil. ID jaringan menamai jaringan, jadi ia memberi tahu daftar mana yang Anda baca dan tidak memberi tahu perangkat mana yang ada di dalamnya. Catat keduanya, lalu cocokkan node ID dengan mesin yang ingin Anda pensiunkan.

Kalau perbandingan itu keliru, Anda menghapus mesin yang masih bekerja sementara perangkat yang tidak diinginkan terus meminta. Daftar lalu tampak benar selama sehari. Itu cukup lama sehingga tidak ada yang menyadarinya, dan justru itulah masalahnya.

Cabut sebelum menghapus

Ubah dulu status otorisasi melalui alur kerja yang didukung pengontrol. Sejak titik itu, upaya bergabung tampil sebagai tidak diotorisasi alih-alih diam-diam memulihkan akses, dan permintaannya terlihat, bukan tidak terlihat.

Penghapusan datang setelahnya, tidak pernah sebagai gantinya. Menghapus catatan anggota yang diotorisasi tidak menyisakan apa pun untuk dicabut. Perangkat meminta lagi, dan pengontrol memperlakukannya sebagai baru.

Untuk mesin yang masih Anda kendalikan, keluar dari jaringan adalah bagian yang berguna dari pensiun. Itu bukan pengganti keputusan administrator atas perangkat yang hilang. Klien yang tidak lagi Anda kendalikan bisa mengabaikan apa pun yang pernah dikatakan padanya.

Di mana kedua operasi berada

Pada pengontrol terkelola, daftar anggota menawarkan kedua tindakan dan memberi label cukup jelas untuk dibedakan. Pada pengontrol yang Anda kelola sendiri, perbedaan yang sama muncul di API dan di konfigurasi lokal, dan biasanya dari situlah kebingungan dimulai.

# 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 apakah anggotanya pernah benar-benar tidak diotorisasi. Catatan yang terus kembali dengan authorized: true tidak pernah dicabut; catatan itu hanya dihapus.

Pastikan dari sumber dayanya, bukan dari daftar

Daftar anggota yang rapi bukan pemeriksaan akses. Coba sumber daya yang dulu dipakai perangkat, dari perangkat itu atau dari mesin yang memegang alamat lamanya, dan pastikan koneksinya gagal. Lalu pastikan pengganti yang disetujui masih berfungsi.

Sertakan rute dan izin layanan dalam pengujian itu. ZeroTier bisa mengotorisasi anggota dan tetap membuatnya tidak bisa mencapai rute terkelola. Izin aplikasi bisa gagal dengan cara yang sama. Keduanya tampak identik dari daftar anggota.

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

Untuk pengontrol yang Anda kelola sendiri, simpan cadangan yang konsisten atas identitas dan konfigurasinya. Pemulihan yang kembali ke keadaan lebih awal bisa membawa otorisasi lama ikut kembali, dan daftar anggota akan tampak persis seperti sebelum pensiun.

Pensiun selesai ketika identitas lama tidak bisa mencapai apa pun dan catatannya sudah hilang. Lakukan dalam urutan itu dan anggotanya berhenti kembali.