สมาชิก 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
สำหรับคอนโทรลเลอร์ที่คุณโฮสต์เอง ให้เก็บสำรองข้อมูลที่สอดคล้องกันของตัวตนและการกำหนดค่า การกู้คืนที่ย้อนกลับไปยังสถานะก่อนหน้าอาจนำสิทธิ์เก่ากลับมาด้วย และรายการสมาชิกจะดูเหมือนก่อนการปลดระวางทุกประการ
การปลดระวางเสร็จสิ้นเมื่อตัวตนเก่าเข้าถึงอะไรไม่ได้และระเบียนหายไป ทำตามลำดับนั้นแล้วสมาชิกจะหยุดกลับมา