WireGuard ในเนมสเปซเครือข่าย: ทำไมซ็อกเก็ตจึงถูกทิ้งไว้ข้างหลัง

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

อาการ: เนมสเปซถูกต้อง แต่ไม่มีแพ็กเก็ต

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

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

นี่ไม่ใช่ข้อบกพร่องของการย้าย และไม่ใช่การตั้งค่าเพียร์ที่ผิด เป็นพฤติกรรมของการทำงานเคอร์เนล และเอกสารเนมสเปซของ WireGuard อธิบายกฎการสร้างไว้โดยตรง

ทำไมซ็อกเก็ตจึงมีถิ่นกำเนิด

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

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

สร้างมันในที่ที่ต้องการซ็อกเก็ต

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

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

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

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

อ่านทั้งสองด้านของเส้นทาง

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

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

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

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