Üyeyi silersiniz, sayfayı kapatırsınız ve bir gün sonra aynı cihaz geri döner. Bu, konsolda bir hata değildir. Cihaz hâlâ çevrimiçiyken ve hâlâ katılmayı isterken kayıt silindiğinde olan budur.

İki işlem yan yana durur ve farklı işler yapar. Biri erişime karar verir, diğeri yalnızca listeyi düzenler.

Geri dönen kayıttan başlayın

Ağı açın ve geri gelen girdiye bakın. node ID'sini, son adresini ve yeniden göründüğü saati not edin. Bunu devreden çıkarmayı düşündüğünüz cihazla karşılaştırın. Görünen ad, birinin yazdığı şeydir ve adres bir sonraki katılmada değişebilir.

node ID kararlı tanımlayıcıdır. Ağ ID'si ağa ad verir, bu yüzden hangi listeyi okuduğunuzu söyler ve içinde hangi cihazın olduğu hakkında hiçbir şey söylemez. İkisini de not edin, sonra node ID'yi devreden çıkarmayı düşündüğünüz makineyle eşleştirin.

Bu karşılaştırmayı yanlış yaparsanız, çalışan bir makineyi kaldırırsınız ve istenmeyen cihaz istemeye devam eder. Sonra liste bir gün boyunca doğru görünür. Kimsenin fark etmeyeceği kadar uzun bir süredir ve sorun tam olarak budur.

Silmeden önce yetkiyi kaldırın

Önce yetki durumunu denetleyicinin desteklediği iş akışıyla değiştirin. O andan itibaren katılma girişimi erişimi sessizce geri yüklemek yerine yetkisiz olarak görünür ve istek görünmez değil görünür olur.

Silme sonra gelir, asla onun yerine değil. Yetkili bir üyenin kaydını kaldırmak geri alınacak bir şey bırakmaz. Cihaz yeniden sorar ve denetleyici onu yeni sayar.

Hâlâ denetlediğiniz bir makine için ağdan ayrılmak devreden çıkarmanın yararlı bir parçasıdır. Kayıp bir cihaz hakkında yöneticinin kararının yerini tutmaz. Artık denetlemediğiniz bir istemci, kendisine söylenen ne olursa olsun yok sayabilir.

İki işlem nerede durur

Barındırılan bir denetleyicide üye listesi iki eylemi de sunar ve ayırt edilebilecek kadar açık etiketler. Kendi barındırdığınız denetleyicide aynı ayrım API'de ve yerel yapılandırmada görünür ve karışıklık genellikle oradan başlar.

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

Üyenin gerçekten yetkisiz olup olmadığını göstermek için bu iki çağrı yeterlidir. authorized: true değeriyle tekrar tekrar geri gelen kayıt hiçbir zaman geri alınmadı; yalnızca silindi.

Listeden değil, kaynaktan doğrulayın

Düzenli bir üye listesi erişim denetimi değildir. Cihazın daha önce kullandığı kaynağı o cihazdan veya eski adresini taşıyan bir makineden deneyin ve bağlantının başarısız olduğunu doğrulayın. Ardından onaylanmış bir yedeğin hâlâ çalıştığını doğrulayın.

Bu testte rotaları ve hizmet izinlerini de hesaba katın. ZeroTier bir üyeyi yetkilendirip yine de yönetilen bir rotaya ulaşamamasına yol açabilir. Bir uygulama izni de aynı şekilde başarısız olabilir. Üye listesinden ikisi de aynı görünür.

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

Kendi barındırdığınız denetleyici için kimliğinin ve yapılandırmasının tutarlı bir yedeğini tutun. Daha eski bir duruma dönen bir geri yükleme eski bir yetkiyi de beraberinde getirebilir ve üye listesi devreden çıkarmadan önceki gibi görünür.

Devreden çıkarma, eski kimlik hiçbir yere ulaşamadığında ve kayıt ortadan kalktığında tamamlanır. Bunu bu sırayla yapın ve üye geri gelmeyi bırakır.

İlgili makaleler