წაშლილი ZeroTier წევრი ბრუნდება: ჯერ ავტორიზაცია გააუქმეთ

წევრს შლით, გვერდს ხურავთ და ერთი დღის შემდეგ იგივე მოწყობილობა ისევ აქ არის. ეს კონსოლის ხარვეზი არ არის. ეს ხდება მაშინ, როცა ჩანაწერი იშლება მოწყობილობის ონლაინ ყოფნისა და შეერთების მოთხოვნის დროს.

ორი ოპერაცია ერთმანეთის გვერდით არსებობს და სხვადასხვა საქმეს აკეთებს. ერთი წვდომას წყვეტს, მეორე კი მხოლოდ სიას აწესრიგებს.

დაიწყეთ დაბრუნებული ჩანაწერიდან

გახსენით ქსელი და დაათვალიერეთ დაბრუნებული ჩანაწერი. ჩაიწერეთ მისი node ID, ბოლო მისამართი და დრო, როცა ის კვლავ გამოჩნდა. შეადარეთ იმ მოწყობილობას, რომლის გამორთვასაც აპირებდით. ნაჩვენები სახელი ის არის, რაც ვინმემ აკრიფა, ხოლო მისამართი შეიძლება შეიცვალოს შემდეგი შეერთებისას.

node ID სტაბილური იდენტიფიკატორია. ქსელის ID ქსელს ასახელებს, ამიტომ ის გეუბნებათ, რომელ სიას კითხულობთ და არაფერს იმაზე, თუ რომელი მოწყობილობაა მასში. ჩაწერეთ ორივე, შემდეგ შეადარეთ node ID იმ მანქანას, რომლის გამორთვასაც აპირებდით.

თუ ეს შედარება შეგეშლებათ, გააუქმებთ მომუშავე მანქანას, სანამ არასასურველი კვლავ ითხოვს შეერთებას. მაშინ სია ერთი დღე სწორად გამოიყურება. ეს საკმარისი დროა, რომ არავინ შეამჩნიოს, და სწორედ ეს არის პრობლემა.

გააუქმეთ სანამ წაშლით

ჯერ შეცვალეთ ავტორიზაციის მდგომარეობა კონტროლერის მხარდაჭერილი სამუშაო პროცესით. ამ მომენტიდან შეერთების მცდელობა არაავტორიზებულად ჩანს, ნაცვლად იმისა, რომ წვდომა ჩუმად აღადგინოს, და მოთხოვნა ხილვადი ხდება, არა უხილავი.

წაშლა შემდეგ მოდის, არასდროს მის ნაცვლად. ავტორიზებული წევრის ჩანაწერის მოცილება გასაუქმებელს არაფერს ტოვებს. მოწყობილობა კვლავ ითხოვს და კონტროლერი მას ახლად თვლის.

მანქანისთვის, რომელსაც ჯერ კიდევ აკონტროლებთ, ქსელიდან გასვლა გამორთვის სასარგებლო ნაწილია. ის არ ცვლის ადმინისტრატორის გადაწყვეტილებას დაკარგულ მოწყობილობაზე. კლიენტი, რომელსაც აღარ აკონტროლებთ, შეიძლება უგულებელყოს ყველაფერი, რაც ეთქვა.

სად არიან ორი ოპერაცია

ჰოსტინგურ კონტროლერზე წევრთა სია ორივე მოქმედებას გვთავაზობს და საკმარისად გარკვევით აღნიშნავს მათ, რომ გაარჩიოთ. საკუთარ კონტროლერზე იგივე განსხვავება API-ში და ლოკალურ კონფიგურაციაში ჩანს, და აქედან იწყება ჩვეულებრივ დაბნეულობა.

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

ეს ორი გამოძახება საკმარისია იმის საჩვენებლად, იყო თუ არა წევრი ოდესმე ნამდვილად არაავტორიზებული. ჩანაწერი, რომელიც არაერთხელ ბრუნდება authorized: true მნიშვნელობით, არასდროს გაუუქმებიათ; ის უბრალოდ წაიშალა.

დაადასტურეთ რესურსიდან, არა სიიდან

მოწესრიგებული წევრთა სია წვდომის შემოწმება არ არის. სცადეთ რესურსი, რომელსაც მოწყობილობა ადრე იყენებდა, იმ მოწყობილობიდან ან მანქანიდან, რომელსაც მისი ძველი მისამართი აქვს, და დაადასტურეთ, რომ კავშირი ვერ ხერხდება. შემდეგ დაადასტურეთ, რომ დამტკიცებული შემცვლელი კვლავ მუშაობს.

ჩართეთ მარშრუტები და სერვისის ნებართვები ამ ტესტში. ZeroTier-ს შეუძლია წევრის ავტორიზება და მიუხედავად ამისა, დაუშვას, რომ ვერ მიაღწიოს მართულ მარშრუტს. აპლიკაციის ნებართვაც შეიძლება ასევე ჩავარდეს. ორივე წევრთა სიიდან ერთნაირად გამოიყურება.

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

საკუთარი კონტროლერისთვის შეინახეთ მისი იდენტობისა და კონფიგურაციის თანმიმდევრული სარეზერვო ასლი. აღდგენა, რომელიც უფრო ადრეულ მდგომარეობას უბრუნდება, შეიძლება ძველი ავტორიზაციაც თან წაიღოს, და წევრთა სია ზუსტად ისე გამოიყურება, როგორც გამორთვამდე.

გამორთვა დასრულებულია, როცა ძველი იდენტობა ვერაფერს აღწევს და ჩანაწერიც გაქრა. გააკეთეთ ეს ამ თანმიმდევრობით და წევრი შეწყვეტს დაბრუნებას.