OpenVPN ใน Docker ไม่สามารถเปิด /dev/net/tun: อะไรขาดหาย

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

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

โหนดอุปกรณ์และความสามารถคือสองประตู

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

การตั้งค่า devices ของ Docker แมปอุปกรณ์โฮสต์เข้าไปในคอนเทนเนอร์ ขณะที่ cap_add ปรับชุดความสามารถ การ bind mount เส้นทางเดียวกันจะนำไฟล์มาไว้ในสายตาโดยไม่ใช้ความหมายของการเข้าถึงอุปกรณ์

ทำซ้ำนอกไฟล์ Compose

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

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun:/dev/net/tun alpine sh -c 'apk add -q iproute2 && ip tuntap add dev tun9 mode tun && ip link show tun9'

การไม่มีโหนดบนโฮสต์หมายถึงโมดูล tun ไม่พร้อมใช้งาน ซึ่งเป็นการแก้ฝั่งโฮสต์ไม่ใช่ฝั่งคอนเทนเนอร์ โหนดที่มีอยู่แต่เปิดในคอนเทนเนอร์ไม่ได้ชี้ไปที่การเข้าถึงอุปกรณ์ และข้อความจะบอกว่า permission denied ไม่ใช่ no such file ลำดับของความล้มเหลวสองอย่างนี้คือการวินิจฉัยทั้งหมด จดบันทึกว่าคุณเห็นอันไหนก่อนเปลี่ยนแฟล็กใด ๆ

ข้อผิดพลาดหลัง TUN เป็นปัญหาที่แตกต่างกัน

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

การคัดลอกทุกการตั้งค่าจากตัวอย่างที่ใช้งานได้คือวิธีที่การแก้เล็ก ๆ กลายเป็นนิยามบริการที่อ่านไม่ออก นำมาเฉพาะที่การติดตั้งนี้ต้องการและบันทึกว่าแต่ละอย่างมีไว้ทำไม

ตรวจสอบอินเทอร์เฟซภายในคอนเทนเนอร์

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

ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9

ความสามารถที่มีอยู่ใน bounding set แต่ไม่มีใน effective set จะทำงานต่างจากความสามารถที่ไม่เคยให้เลย และ capsh จะแสดงทั้งสองอย่าง หากโหนดมีอยู่และความสามารถก็มีอยู่แต่การสร้างยังล้มเหลว แสดงว่า runtime กำลังบังคับใช้อย่างอื่น เช่น โปรไฟล์ seccomp หรือนโยบาย AppArmor ที่จำกัดการทำงาน นั่นคือขอบเขตที่สาม ซึ่ง runtime เป็นผู้บันทึกไม่ใช่แอปพลิเคชัน

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