แอป Linux ทั่วไปใช้ VPN โดยไม่แตะ TUN

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

ติดตามแพ็กเก็ตหนึ่งจากซ็อกเก็ตไปยังอุโมงค์

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

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

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

ตัดสินใจว่าใครต้องใช้อุปกรณ์และใครไม่ต้อง

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

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

การเปลี่ยนสิทธิ์ของอุปกรณ์ไม่ใช่วิธีให้แอปพลิเคชันเข้าถึงปลายทาง มันเพียงย้ายขอบเขตของอุปกรณ์ไปที่อื่น

ตรวจสอบเนมสเปซที่แอปพลิเคชันทำงานจริง

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

ตรวจสอบด้วย ip netns list และ ip -n NAME route หรือดูลิงก์เนมสเปซของกระบวนการ คำตอบมักเห็นได้ในคำสั่งเดียว

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

แยกความสามารถออกจากนโยบายเครือข่าย

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

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

ตั้งชื่อการดำเนินการก่อนตั้งชื่อสิทธิ์ ทั้งสองมักแยกจากกันได้ง่ายกว่าที่เห็น

ตรวจสอบการแยกด้วยสองบัญชี

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

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