ได้รับอนุญาตใน ZeroTier แต่ไม่มีที่อยู่? สองการตั้งค่าแยกกัน
การอนุมัติสมาชิกและการมอบที่อยู่ให้เป็นสองการตั้งค่า อ่านพูล โหมดการกำหนด และสถานะที่ไคลเอนต์ใช้ก่อนจะสร้าง IP ขึ้นมาเอง
ZeroTier แสดงสมาชิกเป็น OK เครือข่ายเชื่อมต่อแล้ว และยังไม่มีที่อยู่ให้ ping การผสมกันนี้รู้สึกเหมือนบั๊ก และมักเป็นการตั้งค่าที่แยกออกจากกัน: การอนุมัติสมาชิกเป็นสวิตช์หนึ่ง และการมอบที่อยู่ให้เป็นอีกสวิตช์หนึ่ง เครือข่ายสามารถรับอุปกรณ์ได้และไม่เคยกำหนดอะไรให้เลย เพราะพูลที่อยู่หรือโหมดการกำหนดไม่เคยถูกตั้งค่า
อ่านทั้งสองด้านก่อนจะเปลี่ยนด้านใดด้านหนึ่ง คำตอบปรากฏในสองที่ และมีเพียงที่เดียวเท่านั้นที่อยู่บนคอนโทรลเลอร์
การอนุญาตและการกำหนดเป็นสวิตช์คนละตัว
การอนุญาตตอบว่าโหนดนี้เข้าร่วมเครือข่ายได้หรือไม่ การกำหนดที่อยู่ตอบว่าเครือข่ายมอบอะไรให้เมื่อเข้าร่วม และคำตอบนั้นมาจากพูลที่อยู่บวกกับโหมดการกำหนด ไม่มีการตั้งค่าใดบ่งบอกอีกอย่างหนึ่ง อย่างหนึ่งคือการอนุญาต อีกอย่างคือการจัดสรร
การตั้งค่าคอนโทรลเลอร์มักมีเส้นทางที่จัดการได้ ช่วงที่อยู่ และโหมดที่ตัดสินว่าใช้การกำหนดอัตโนมัติหรือไม่ การคัดลอกรหัสเครือข่ายจากสภาพแวดล้อมอื่นนำมาซึ่งสมาชิกภาพและไม่มีอะไรจากการตั้งค่านั้น
นี่คือเหตุผลที่อุปกรณ์อาจดูปกติในรายชื่อสมาชิก ขณะที่คอลัมน์ที่อยู่ที่กำหนดยังว่างอยู่ คอนโทรลเลอร์ยอมรับแล้วและไม่มีอะไรจะให้ ทั้งสองข้อความเป็นจริงในเวลาเดียวกัน
| Layer | What it decides | Where it is configured |
|---|---|---|
| Membership | Whether the node may join | Member authorization on the network |
| Pool | Which addresses exist to hand out | Network address range |
| Assignment mode | Whether they are handed out automatically | Network v4/v6 assignment settings |
การอ่านสถานะจริงของสมาชิก
ถามไคลเอนต์ว่าได้รับอะไรจริง ไม่ใช่คอนโทรลเลอร์ตั้งใจจะให้อะไร รายการธรรมดาแสดงคอลัมน์สถานะและที่อยู่ และรูปแบบ JSON แสดงการตั้งค่าเครือข่ายที่ไคลเอนต์ใช้ รวมถึงที่อยู่และเส้นทางที่จัดการ
zerotier-cli listnetworks
zerotier-cli -j listnetworks | jq '.networks[] | {nwid, status, assignedAddresses}'เปรียบเทียบผลลัพธ์ทั้งสองสำหรับรหัสเครือข่ายเดียวกัน ไม่ใช่อะแดปเตอร์กายภาพที่ปรากฏในรายการของระบบปฏิบัติการเอง แถวที่รายงาน OK ด้วยชุดที่อยู่ว่างยืนยันช่องว่างในการกำหนด ไม่ใช่ความผิดพลาดของการเชื่อมต่อ การอ่านแถวผิดคืออีกครึ่งหนึ่งของความผิดพลาดนี้
สถานะ ACCESS_DENIED ชี้กลับไปที่การอนุญาต และนั่นคือการซ่อมอีกแบบ ถ้าคำสั่งอ่านโทเคนการพิสูจน์ตัวตนภายในเครื่องไม่ได้เลย ปัญหาคือสิทธิ์ภายในเครื่อง ไม่ใช่การปฏิเสธจากคอนโทรลเลอร์ และการแก้ไขอยู่ที่เครื่องที่คุณนั่งอยู่
เมื่อไคลเอนต์เพิกเฉยต่อสิ่งที่คอนโทรลเลอร์ส่งมา
ไคลเอนต์มีการตั้งค่าของตัวเองที่ตัดสินว่าจะใช้การตั้งค่าที่จัดการหรือไม่ โปรไฟล์ที่ปิดที่อยู่ที่จัดการ เส้นทางที่จัดการ หรือการจัดการเส้นทางเริ่มต้นจะทิ้งสิ่งที่เครือข่ายส่งมา และรายชื่อสมาชิกจะยังดูถูกต้องจากฝั่งคอนโทรลเลอร์
แฟล็กเหล่านั้นมีผลกับโหนดภายในเครื่องเท่านั้น การเปลี่ยนไม่มีผลกับสิ่งที่สมาชิกอื่นได้รับ และไม่ได้ซ่อมพูลที่ไม่เคยถูกกำหนด
ดังนั้นการวินิจฉัยมีสองแขนง: คอนโทรลเลอร์ไม่มีที่อยู่จะให้ หรือไคลเอนต์ปฏิเสธที่อยู่ที่ได้รับ ทั้งสองนำไปสู่การซ่อมที่ต่างกันบนเครื่องที่ต่างกัน ผลลัพธ์ JSON แยกทั้งสอง เพราะที่อยู่หายไปจากการตั้งค่าเครือข่าย หรือมีอยู่แต่หายไปจากสถานะที่ไคลเอนต์ใช้
สิ่งที่ควรซ่อมแทนการสร้างที่อยู่ขึ้นมา
การพิมพ์ที่อยู่แบบคงที่ตามอำเภอใจเป็นทางเลือกที่สามที่น่าดึงดูดและแย่ที่สุด ที่อยู่แบบสุ่มอาจชนกับโหนดอื่น อยู่นอกเส้นทางที่เครือข่ายประกาศ หรือตกในช่วงที่กฎไฟร์วอลล์จัดการต่างออกไป นอกจากนี้ยังซ่อนพูลที่หายไปจากทุกคนที่จะดูเครือข่ายต่อไป ซ่อมการกำหนดแทน และปล่อยให้คอนโทรลเลอร์กับไคลเอนต์ตกลงผลลัพธ์ร่วมกัน
ถามผู้ดูแลว่าเครือข่ายควรจ่ายอะไร แล้วตรวจสอบว่าพูลครอบคลุมช่วงที่ต้องการและโหมดการกำหนดเปิดอยู่ เข้าร่วมใหม่หลังการเปลี่ยนแปลง แทนที่จะคาดว่าไคลเอนต์จะไปถึงการตั้งค่าใหม่เองทันที
เมื่อที่อยู่ปรากฏ ตรวจสอบสิ่งที่คุณต้องการจริง: เพียร์ บริการ หรือซับเน็ตหลังเกตเวย์ การเข้าถึง LAN หลังสมาชิกต้องมีการกำหนดเส้นทางและการส่งต่อเกินกว่าสมาชิกภาพ และการเข้าถึงอินเทอร์เน็ตทั่วไปต้องมีโหนดทางออก ที่อยู่ที่ใช้งานได้จึงเป็นจุดเริ่มต้นของการทดสอบนั้น ไม่ใช่จุดสิ้นสุด