ซ็อกเก็ตการจัดการ OpenVPN: ช่องทางควบคุม ไม่ใช่เมตริก

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

ความเชื่อ และราคาที่ต้องจ่าย

ความเชื่อคือ listener การจัดการเทียบเท่ากับปลายทางเมตริก: ต่อ collector อ่านตัวนับ แล้วไปต่อ สิ่งที่เกิดขึ้นจริงคือ collector เปิดเซสชันที่มีความสามารถในการควบคุม และสมมติฐานอื่นทั้งหมดที่คุณมีเกี่ยวกับการติดตั้งตอนนี้ขึ้นอยู่กับว่า collector นั้นประพฤติตัวดี

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

สิ่งที่ไคลเอนต์ที่ได้รับอนุมัติถืออยู่จริง

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

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

ซ็อกเก็ตที่เป็นของเรา ไม่ใช่ซ็อกเก็ตที่เปิด

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

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

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

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

การเผยแพร่ผ่าน TCP ไม่ใช่การออกแบบเดียวกัน

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

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

dependency ตอนเริ่มต้นที่คุณไม่ได้ขอ

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

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

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

การยอมรับมีหน้าตาอย่างไร

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

เอกสารของอินเทอร์เฟซการจัดการ อธิบายโมเดลไคลเอนต์เดียวและลักษณะพิเศษของโปรโตคอล และนั่นคือส่วนที่คุ้มค่าจะอ่านก่อนที่คุณจะชี้แดชบอร์ดไปที่มัน