ไคลเอนต์การจัดการได้เพียงตัวเดียว: ทำไมมอนิเตอร์ของคุณจึงเตะ GUI ออกไป

GUI บนเดสก์ท็อปถือการเชื่อมต่อการจัดการไว้ สคริปต์ตรวจสอบที่พยายามเปิดการเชื่อมต่อของตัวเองจึงอ่านอะไรไม่ได้ หรือแย่กว่านั้นคือ GUI หยุดตอบสนองพรอมป์ ข้อสรุปที่พบบ่อยคือเดมอนไม่เสถียร แต่ในเดมอนของชุมชน ข้อจำกัดนี้เป็นเจตนา: อินเทอร์เฟซควบคุมให้บริการไคลเอนต์การจัดการที่เชื่อมต่ออยู่ครั้งละหนึ่งราย และจำนวนนั้นไม่เกี่ยวกับจำนวนผู้ใช้ที่ VPN รองรับได้เลย

ซ็อกเก็ตเดียว ผู้ถือครองเดียว

ช่องทางการจัดการรับไคลเอนต์ที่เชื่อมต่อได้เพียงรายเดียว เมื่อรายที่สองมาถึงในขณะที่รายแรกยังใช้งานอยู่ มันจะรอหรือถูกปฏิเสธ และไม่มีโหมดสมาชิกขนานที่ซ่อนอยู่หลังตัวเลือกใด ๆ การตัดการเชื่อมต่อของผู้ถือครองปัจจุบันทำให้เดมอนรับรายถัดไปได้ และนั่นคือการส่งต่อ ไม่ใช่ช่องทางที่สอง

สิ่งนี้ทำให้เครื่องมือเพิ่มเติมทุกตัวกลายเป็นคู่แข่ง ถ้า GUI ถือการเชื่อมต่อไว้ สคริปต์ที่คอยสอบถามจะเชื่อมต่อไม่สำเร็จ หรือสำเร็จได้ก็ต่อเมื่อ GUI ยอมแพ้ไปแล้ว และลำดับนี้จะเกิดซ้ำในการเชื่อมต่อใหม่ครั้งถัดไป ถ้าสคริปต์เชื่อมต่อก่อน GUI จะสูญเสียเส้นทางการควบคุมและพรอมป์ก็หยุดทำงาน ไม่มีเครื่องมือใดรายงานความขัดแย้ง เพราะแต่ละตัวเห็นเพียงคำสั่งที่ล้มเหลวของตัวเอง

ตัดสินใจว่าคอมโพเนนต์ใดถือการควบคุม

เลือกผู้ถือครองหนึ่งรายสำหรับช่องทางโต้ตอบ และปล่อยให้เป็นสิ่งเดียวที่เชื่อมต่อ GUI ที่จัดการการเชื่อมต่อ สคริปต์ที่ตอบพรอมป์การยืนยันตัวตน และตัวควบคุมที่สิ้นสุดเซสชัน ล้วนนับเป็นผู้ถือครอง และมีเพียงรายเดียวเท่านั้นที่รับบทบาทนี้ได้

เมื่อ GUI ถือการเชื่อมต่อ ให้ใช้การผสานรวมที่ GUI นั้นมีให้ แทนที่จะต่อสู้กับมัน การแข่งขันกับผู้ถือครองเพื่อแย่งซ็อกเก็ตทำให้เกิดความล้มเหลวเป็นระยะซึ่งผู้ใช้เห็นว่าเป็นเรื่องสุ่ม และคนที่กำลังดีบักมักเห็นเพียงครึ่งหลังของการแข่งขัน บันทึกว่าโปรเซสใดเชื่อมต่อก่อนหลังรีบูต เพราะลำดับนั้นเป็นตัวกำหนดว่าใครชนะทุกครั้ง มอนิเตอร์ที่เริ่มก่อน GUI จะยึดช่องทางไว้จนกว่า GUI จะยอมแพ้

ใช้สแนปช็อตสถานะสำหรับตัวเก็บข้อมูล

ความต้องการตรวจสอบส่วนใหญ่ต้องการรายการ ไม่ใช่บทสนทนา ไฟล์สถานะที่เขียนเป็นระยะตอบโจทย์นั้นโดยไม่แตะช่องทางควบคุม และยังทำงานต่อไปในขณะที่ GUI ยังเชื่อมต่ออยู่

status /run/openvpn/server.status 10
management /run/openvpn/server.sock unix

ช่วงเวลาเป็นงบประมาณความสด ดังนั้นตั้งค่าตามสิ่งที่แดชบอร์ดต้องการจริง ไม่ใช่ค่าที่น้อยที่สุดที่ดูปลอดภัย สแนปช็อตที่เขียนทุกไม่กี่วินาทีนั้นถูก แต่สคริปต์ที่เชื่อมต่อใหม่กับซ็อกเก็ตควบคุมทุกไม่กี่วินาทีนั้นไม่ถูก เพราะการเชื่อมต่อใหม่แต่ละครั้งต้องแข่งขันกับผู้ถือครอง

สแนปช็อตไม่ใช่ประวัติและไม่ใช่ฟีดเหตุการณ์ การเชื่อมต่อที่เข้ามาและออกไปภายในช่วงเวลาเดียวกันจะไม่ปรากฏเลย ดังนั้นข้อกำหนดด้านการตรวจสอบจึงไม่สามารถตอบสนองได้ด้วยการสอบถามไฟล์ที่เขียนทับตัวเอง ถ้าคุณต้องรู้ว่าผู้ใช้เคยเชื่อมต่อหรือไม่ สแนปช็อตคือเครื่องมือที่ผิด

การกระจายคือการออกแบบ ไม่ใช่โหมด

ถ้าผู้บริโภคหลายรายต้องการข้อมูลการจัดการแบบสดจริง ๆ ให้วางคอมโพเนนต์ที่เชื่อถือได้หนึ่งตัวไว้หน้าซ็อกเก็ต และปล่อยให้มันเผยแพร่ข้อสังเกตที่คัดสรรอย่างแคบไปยังส่วนที่เหลือ คอมโพเนนต์นั้นถือการเชื่อมต่อใหม่ พรอมป์การยืนยันตัวตน และการตัดสินใจว่าอะไรปลอดภัยที่จะเปิดเผย

สร้างมันอย่างตั้งใจ: กำหนดว่าคิวรีใดได้รับอนุญาต บันทึกว่าใครเป็นผู้ถาม และหลีกเลี่ยงไม่ให้ชั้นกระจายกลายเป็นแผงควบคุมระยะไกลโดยไม่ตั้งใจ เดมอนไม่มีโหมดหลายไคลเอนต์ให้เปิด และไม่มีบรรทัดการกำหนดค่าใดสร้างมันขึ้นมา มองว่าผู้ถือครองเป็นส่วนหนึ่งของขอบเขตความปลอดภัย เพราะมันถืออินเทอร์เฟซที่ตัดคนออกได้ การรีสตาร์ตมันควรเป็นงานประจำที่มีเส้นทางการกู้คืนที่บันทึกไว้

มองซ็อกเก็ตเป็นสิทธิพิเศษ ไม่ใช่ตัวชี้วัด

อินเทอร์เฟซการจัดการตัดการเชื่อมต่อผู้ใช้ได้ เปลี่ยนสถานะ และอ่านเหตุการณ์ที่ระบุชื่อคน รหัสผ่านของมันยืนยันตัวไคลเอนต์และไม่ได้เข้ารหัสการรับส่ง ดังนั้นผู้ดักฟังบนเครือข่ายจึงเปิดเผยบทสนทนาให้ใครก็ตามที่สังเกตได้

เลือกซ็อกเก็ตภายในเครื่องหรือตัวรับฟังที่จำกัดอย่างเข้มงวด และตรวจสอบว่าตัวเก็บข้อมูลของคุณกำลังส่งถึงโปรเซสใดจริง ๆ เพราะผลิตภัณฑ์เซิร์ฟเวอร์มี API การจัดการของตัวเองซึ่งทำงานต่างออกไป ตัวเก็บข้อมูลที่ชี้ไปยังเดมอนผิดจะให้ข้อสรุปที่มั่นใจแต่ผิด ยืนยันเส้นทางและโปรเซสเจ้าของก่อนดีบักคิวรีที่ไม่ส่งอะไรกลับมา