โปรเซส VPN ของคุณต้องใช้ความสามารถ Linux อะไรบ้าง
การตั้งค่าอินเทอร์เฟซ เส้นทาง การเข้าถึงอุปกรณ์ และซ็อกเก็ตทั่วไปเป็นสิทธิ์แยกกัน ระบุการดำเนินการที่ล้มเหลวก่อนให้ CAP_NET_ADMIN
เดมอน VPN ต้องการการดำเนินการเครือข่ายที่ได้รับสิทธิ์พิเศษ แม้ว่าแอปพลิเคชันทั่วไปจะเปิดซ็อกเก็ตขาออกได้โดยไม่ต้องมีสิทธิ์ใด ๆ ช่องว่างตรงนี้คือจุดที่ข้อผิดพลาดเรื่องความสามารถส่วนใหญ่เริ่มต้นขึ้น มีคนเห็นข้อผิดพลาดเรื่องสิทธิ์ ให้ทั้งชุด แล้วบริการก็ทำงานด้วยเหตุผลที่ภายหลังไม่มีใครอธิบายได้ แนวทางด้านล่างเริ่มจากการดำเนินการที่ล้มเหลว จับคู่กับการอนุญาตหนึ่งอย่าง แล้วตรวจบริบทที่โปรเซสทำงานอยู่จริง การทำงานเป็น root แบบไม่จำกัดเป็นคำตอบที่ใช้ได้สำหรับบางการติดตั้ง แต่ควรเป็นการตัดสินใจไม่ใช่ค่าเริ่มต้น
เริ่มจากการดำเนินการที่ล้มเหลว
อ่านข้อผิดพลาดก่อนอ่านบทช่วยสอน «การดำเนินการไม่ได้รับอนุญาต» เมื่อเปลี่ยนอินเทอร์เฟซ การปฏิเสธที่จะเปิดโหนดอุปกรณ์ และการผูกพอร์ตต่ำล้มเหลว เป็นปัญหาสามอย่างที่แตกต่างกันด้วยการอนุญาตที่แตกต่างกันสามแบบ ถ้าโปรเซสเริ่มทำงานและล้มเหลวเฉพาะตอนเปลี่ยนเส้นทางครั้งแรก นั่นก็บอกว่าการสร้างอินเทอร์เฟซสำเร็จแล้ว ซึ่งทำให้คำตอบแคบลงมาก
ทำซ้ำความล้มเหลวโดยหยุดบริการไว้ แล้วเริ่มใน foreground ภายใต้ผู้ใช้เดียวกันหากการใช้งานอนุญาต ข้อผิดพลาดที่มองเห็นได้ดีกว่าบรรทัดบันทึกที่ต้องเดา และทำให้เห็นความแตกต่างระหว่างปัญหาความสามารถกับการปฏิเสธของ SELinux หรือ AppArmor อย่างชัดเจน
จับคู่แต่ละการดำเนินการกับการอนุญาตหนึ่งอย่าง
ตารางนี้เป็นแผนที่เริ่มต้น ไม่ใช่สิ่งทดแทนเอกสารของการใช้งาน:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
สองแถวในตารางนั้นคือแถวที่คนมักสับสน การเปิด /dev/net/tun เป็นคำถามเรื่องสิทธิ์ของไฟล์ การขอให้เคอร์เนลกำหนดค่าสิ่งที่คุณเปิดเป็นคำถามเรื่องความสามารถ การให้ CAP_NET_ADMIN ไม่ได้แก้ไขโหนดอุปกรณ์ที่ผู้ใช้บริการของคุณอ่านไม่ได้ และการแก้ไขโหนดก็ไม่ได้ให้สิทธิ์เส้นทางแก่คุณ ตรวจทั้งสองอย่างก่อนเปลี่ยนอย่างใดอย่างหนึ่ง
WireGuard ในเคอร์เนลและโปรแกรมอุโมงค์ในพื้นที่ผู้ใช้ก็ไม่มีความต้องการเหมือนกัน เส้นทางของมอดูลเคอร์เนลกำหนดค่าอินเทอร์เฟซที่มีอยู่ผ่าน netlink ขณะที่การใช้งานในพื้นที่ผู้ใช้อาจต้องใช้อุปกรณ์และสำหรับการขนส่งบางแบบต้องใช้ซ็อกเก็ตดิบด้วย
อ่านบริบท: บริการ คอนเทนเนอร์ หรือเชลล์
ความสามารถในเนมสเปซเครือข่ายของโฮสต์อาจส่งผลได้มากกว่าการดำเนินการเดียวกันในสแตกที่แยกออกโดยเจตนา สภาพแวดล้อมรันไทม์ของคอนเทนเนอร์มักเริ่มด้วยชุดขอบเขตที่ลดลง การเพิ่ม NET_ADMIN ให้คอนเทนเนอร์ที่แชร์เครือข่ายของโฮสต์เป็นการอนุญาตที่ใหญ่กว่ามากเมื่อเทียบกับการเพิ่มให้คอนเทนเนอร์ที่มีเนมสเปซเครือข่ายของตัวเองและไม่มีการเมานต์จากโฮสต์
สำหรับยูนิต systemd ให้อ่านสิ่งที่ถูกบังคับใช้จริง ไม่ใช่สิ่งที่ไฟล์ยูนิตดูเหมือนจะบอก: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities รายงานค่าที่มีผล ซึ่งอาจถูกกำหนดโดย drop-in ที่คุณลืม ถามหาค่าที่มีผล ไม่ใช่ค่าที่ตั้งใจ ความสามารถ ambient สำคัญเพราะบริการที่ไม่ใช่ root สูญเสียความสามารถเมื่อผ่าน exec หากไม่มีสิ่งเหล่านี้
ใช้การตั้งค่าที่แพ็กเกจหรืออิมเมจรองรับเป็นพื้นฐาน อย่าเพิ่มสิทธิ์ซ็อกเก็ตดิบหรือโหมดสิทธิ์พิเศษเพียงเพราะบทช่วยสอนอื่นระบุไว้สำหรับเครื่องมืออื่น เหตุผลนั้นไม่ได้ถ่ายโอนอะไรเลยและทำให้คุณเสียการแยกส่วนที่คุณจ่ายไป หากไม่แน่ใจ อย่าให้อะไรเลย และอ่านบันทึกของการใช้งานสำหรับการดำเนินการที่ต้องการจริง ๆ
สังเกตว่าเกิดอะไรขึ้นหลังจากสิทธิ์ลดลง
เดมอนหลายตัวเริ่มด้วยสิทธิ์ กำหนดค่าอินเทอร์เฟซ แล้วเปลี่ยนไปยังผู้ใช้ที่ไม่มีสิทธิ์และคงอุโมงค์ไว้ จากจุดนั้นโปรเซสไม่สามารถเพิ่มเส้นทาง เขียนกฎไฟร์วอลล์ใหม่ หรือเปิดอุปกรณ์ที่มีสิทธิ์ใหม่ได้ ซึ่งไม่เป็นไรจนกว่าการเชื่อมต่อใหม่จะต้องการสิ่งนั้นพอดี การอ่านไฟล์และการเรียกฮุกในภายหลังอาจล้มเหลวด้วยเหตุผลเดียวกัน
ทดสอบวงจรชีวิตทั้งหมดไม่ใช่วินาทีแรก: การเริ่มต้น การต่ออายุหรือเชื่อมต่อใหม่ และการล้างข้อมูลเมื่อหยุด การสร้างอินเทอร์เฟซสำเร็จครั้งแรกไม่ได้พิสูจน์ว่าทุกการดำเนินการที่มีสิทธิ์ในภายหลังจะยังทำงานอยู่ และความล้มเหลวมักปรากฏขึ้นหลายชั่วโมงต่อมาในการผลิต
การใช้งานที่คงอุโมงค์เปิดไว้ระหว่างการเปลี่ยนผู้ใช้มักจับคู่กับตัวเลือกในการคงอุโมงค์และคีย์ไว้ ในฝั่ง systemd คำถามที่เทียบเท่าคือชุดความสามารถของยูนิตอยู่รอดจากการเปลี่ยนผู้ใช้ที่คุณกำหนดค่าไว้หรือไม่
บันทึกการอนุญาตและเหตุผล
เขียนการอนุญาตที่แน่นอน การดำเนินการที่มันเปิดทาง และข้อผิดพลาดที่มันแก้ไข บรรทัดเดียวในบันทึกการติดตั้ง — «CAP_NET_ADMIN ในเนมสเปซเครือข่ายของยูนิต จำเป็นสำหรับการเปลี่ยนเส้นทางหลังเชื่อมต่อใหม่» — ก็เพียงพอที่จะหยุดคนถัดไปไม่ให้ขยายการอนุญาตอีก
จากนั้นอ่านชุดที่มีผลอีกครั้งหลังทุกการอัปเกรด ผู้จำหน่ายเพิ่มฟีเจอร์ อิมเมจเปลี่ยนค่าเริ่มต้น และความสามารถที่ไม่จำเป็นเมื่อปีที่แล้วอาจกลายเป็นตัวรองรับโดยไม่มีใครสังเกต