คอนเทนเนอร์ LXD เปิด /dev/net/tun ไม่ได้? ตรวจสอบรายการ unix-char

LXD เปิดเผยอุปกรณ์อักขระของโฮสต์ให้คอนเทนเนอร์โดยการเพิ่มโหนดอุปกรณ์ ไม่ใช่โดยการสอนให้ผู้เยี่ยมสร้างขึ้นเอง ถ้าคอนเทนเนอร์ไม่มี /dev/net/tun อุปกรณ์อาจมีอยู่บนโฮสต์แต่ผู้เยี่ยมก็ยังเปิดไม่ได้ รายการ unix-char คือครึ่งหนึ่งฝั่งผู้จัดการของเส้นทางนั้น และมันตั้งใจให้แคบกว่าคอนเทนเนอร์ที่ได้สิทธิพิเศษ นั่นคือเหตุผลที่โหนดฝั่งโฮสต์และโหนดฝั่งคอนเทนเนอร์ควรถูกตรวจแยกกัน

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

รายการ unix-char เปลี่ยนอะไรจริง ๆ

อุปกรณ์ unix-char บอก LXD ให้เปิดเผยอุปกรณ์อักขระหนึ่งตัวของโฮสต์ที่เส้นทางที่เลือกภายในคอนเทนเนอร์ รายการมีสามส่วนที่สำคัญ คือ ป้ายชื่ออุปกรณ์ที่ผู้จัดการใช้ เส้นทาง source บนโฮสต์ และ path ที่ผู้เยี่ยมเห็น มีเพียงสองส่วนหลังที่อธิบายตัวอุปกรณ์ การพิมพ์ผิดในส่วนใดส่วนหนึ่งจะสร้างโหนดในตำแหน่งที่ไคลเอนต์ไม่เคยเปิด

บนโฮสต์อุปกรณ์มักเป็น /dev/net/tun ภายในคอนเทนเนอร์คุณจะเก็บเส้นทางเดิมหรือเลือกเส้นทางอื่นก็ได้ แต่เส้นทางต้องตรงกับสิ่งที่ไคลเอนต์ VPN คาดหวัง การเก็บ /dev/net/tun ไว้ช่วยหลีกเลี่ยงปัญหาการกำหนดค่าที่สอง เพราะไคลเอนต์ส่วนใหญ่เปิดเส้นทางนั้นโดยไม่ถาม

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

ประกาศอุปกรณ์บนอินสแตนซ์ ไม่ใช่ภายในผู้เยี่ยม

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

lxc config device add vpnbox tun unix-char source=/dev/net/tun path=/dev/net/tun
lxc config device show vpnbox

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

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

จับคู่เจ้าของและโหมดกับโปรเซสของผู้เยี่ยม

รายการ unix-char กำหนด uid, gid และ mode ให้โหนดภายในคอนเทนเนอร์ได้ ใช้ค่าเหล่านี้ให้ตรงกับบัญชีที่รันไคลเอนต์ VPN แทนที่จะเปิดอุปกรณ์ให้ผู้ใช้ทุกคนหรือเปลี่ยนคอนเทนเนอร์เป็นโหมดสิทธิพิเศษ

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

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

รู้ว่ารายการไม่ได้ให้อะไร

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

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

การเสียบแบบร้อนเป็นทางเลือกและชัดเจน รายการที่มี required=false ต้องมีเส้นทางต้นทางและอาจปรากฏหรือหายไปเมื่ออุปกรณ์ของโฮสต์เปลี่ยน วงจรชีวิตแบบนั้นเหมาะกับฮาร์ดแวร์ที่เข้ามาและจากไป สำหรับอุปกรณ์ TUN ที่ VPN ต้องใช้ตอนบูต รายการแบบทางเลือกอาจทำให้บริการเริ่มก่อนที่เงื่อนไขเบื้องต้นจะมีอยู่

ตรวจสอบการมองเห็น การเปิด และอินเทอร์เฟซตามลำดับนั้น

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

lxc exec vpnbox -- ls -l /dev/net/tun
lxc exec vpnbox -- sh -c 'test -c /dev/net/tun && echo char-device-ok'

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

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