เนมสเปซเครือข่ายของ Linux สำหรับ VPN: สิ่งที่มันไม่ได้แยกออกจากกัน

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

เนมสเปซเป็นเจ้าของอะไร และซ็อกเก็ตถือกำเนิดที่ไหน

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

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

สิ่งที่เนมสเปซไม่ได้แยกออกจากกัน

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

ทางแก้คือไฟล์ต่อเนมสเปซที่ /etc/netns/<name>/resolv.conf หรือ bind mount ของไฟล์ที่เตรียมไว้ ชี้ไปยังรีโซลเวอร์ที่เข้าถึงได้จากข้างใน การแก้ไข /etc/resolv.conf บนโฮสต์ไม่เปลี่ยนอะไรที่เนมสเปซมองเห็น

การวางตำแหน่งโปรเซสคือการควบคุม

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

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

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

ทดสอบจากบริบทของแอปพลิเคชัน

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

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

การส่งต่อ นโยบายเมื่อล้มเหลว และการทำความสะอาด

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

บันทึกชื่อเนมสเปซ อินเทอร์เฟซ และใครเป็นเจ้าของการกำหนดค่า เพื่อให้การทำความสะอาดลบเฉพาะสิ่งที่การติดตั้งใช้งานสร้างขึ้น การรีเซ็ตเครือข่ายของโฮสต์ระหว่างการย้อนกลับจะเปลี่ยนการทำความสะอาดให้กลายเป็นเหตุขัดข้อง หน้า network_namespaces(7) นั้นสั้นและคุ้มค่าที่จะอ่านก่อนออกแบบเส้นทางนั้น