OpenVPN บน VPS: ไม่มีอุปกรณ์ /dev/net/tun ให้เปิด
การกำหนดค่าปกติมักเรียบร้อย: guest มองไม่เห็นอุปกรณ์ tun แยกให้ออกว่าเป็น VM หรือคอนเทนเนอร์ที่ใช้เคอร์เนลร่วมกัน แล้วแก้ชั้นที่เป็นเจ้าของเคอร์เนล
การเริ่มครั้งแรกล้มเหลวพร้อมข้อความเกี่ยวกับ /dev/net/tun หรืออุปกรณ์ TUN/TAP ที่เปิดไม่ได้ ยังไม่ได้อ่านใบรับรอง จึงไม่มีอะไรผิดในโปรไฟล์ เดมอนกำลังขอเคอร์เนลให้สร้างออบเจกต์ที่ guest นี้ไม่มี
ออบเจกต์นั้นคืออุปกรณ์อักขระที่โมดูล tun รองรับ การจะสร้างได้หรือไม่ขึ้นกับว่าใครเป็นเจ้าของเคอร์เนล
เดมอนขออะไรจากเคอร์เนล
OpenVPN เปิด /dev/net/tun และขออินเทอร์เฟซจากไดรเวอร์ ไดรเวอร์คือโมดูล tun และโหนดอุปกรณ์คือแฮนเดิลที่ผู้ใช้สเปซใช้เข้าถึงมัน ถ้าโมดูลยังไม่ถูกโหลด โหนดอาจหายไปหรือการเปิดอาจล้มเหลว ทั้งสองสภาพไม่ได้รับการแก้ด้วยการแก้ไข server.conf
อ่านข้อผิดพลาดนี้เป็นคำถามเรื่องแพลตฟอร์มก่อน ข้อผิดพลาดการกำหนดค่าจะเกิดหลังอุปกรณ์เปิดขึ้น ไม่ใช่ก่อนหน้า
VM หรือ guest ที่ใช้เคอร์เนลร่วมกัน
บน KVM, Xen หรือเครื่องเสมือนเต็มรูปแบบอื่น คุณควบคุมเคอร์เนลเองได้ คุณโหลดโมดูลและสร้างโหนดได้ บน OpenVZ, Virtuozzo หรือคอนเทนเนอร์สไตล์ LXC guest ใช้เคอร์เนลของโฮสต์ร่วมกัน ดังนั้น root ข้างในจึงโหลดโมดูลที่โฮสต์ไม่ได้โหลดไม่ได้
ความล้มเหลวเดียวกันจึงมีเจ้าของสองแบบที่ต่างกันมาก ในกรณีแรกคุณแก้ได้จากภายในอินสแตนซ์ ในกรณีที่สองคุณกำลังขอให้โฮสต์หรือผู้ให้บริการเปิดอะไรบางอย่าง
รัน ls -l /dev/net/tun, lsmod | grep tun และ ip -brief link show ก่อนตัดสินว่าคุณอยู่ในกรณีใด
บน VM ให้โหลดโมดูลตอนบูต
บนเครื่องเสมือน modprobe tun มักสร้างโหนดอุปกรณ์ให้ ตรวจว่ามันปรากฏแล้ว จากนั้นทำให้การโหลดถาวรผ่านการกำหนดค่าโมดูลของดิสทริบิวชัน แทนที่จะพึ่งคำสั่งที่พิมพ์ครั้งเดียว โหนดที่หายไปหลังรีบูตจะกลายเป็นตั๋วเดิมในเดือนหน้า
ตรวจด้วยว่าเคอร์เนลที่คุณบูตมีโมดูลนี้อยู่หรือไม่ เคอร์เนลของผู้ให้บริการที่ตัดทอนอาจไม่มี
ถ้าโหนดมีอยู่แต่ยังเปิดไม่ได้ ผู้ต้องสงสัยถัดไปคือสิทธิ์และหมายเลข major/minor ของอุปกรณ์ นั่นคือการแก้ไขภายในเครื่อง ไม่ใช่คำขอถึงผู้ให้บริการ
ในคอนเทนเนอร์ โฮสต์เป็นเจ้าของอุปกรณ์
ในคอนเทนเนอร์ อุปกรณ์และความสามารถเป็นข้อกำหนดสองอย่างแยกกัน รันไทม์ต้องส่ง /dev/net/tun ผ่านเข้ามา และคอนเทนเนอร์ต้องมีความสามารถเครือข่ายเพื่อสร้างอินเทอร์เฟซ รันไทม์แบบ rootless ที่ไม่ให้ทั้งสองอย่างจะยังสร้างข้อผิดพลาดการเปิดเดิม ไม่ว่าโปรไฟล์จะเขียนอย่างไร โฮสต์ OpenVZ จำนวนมากมีสวิตช์ TUN/TAP ในแผงลูกค้า การเปิดมันพร้อมรีสตาร์ทมักเป็นทางแก้ทั้งหมด
ถามผู้ให้บริการสองคำถามที่ชัดเจน: โมดูล tun ถูกโหลดบนโฮสต์แล้วหรือยัง และอุปกรณ์พร้อมใช้ภายในอินสแตนซ์นี้หรือไม่ ตั๋วที่คลุมเครือได้คำตอบที่คลุมเครือ
ทำไมการสร้างโมดูลใหม่จึงแทบไม่ช่วย
การสร้างโมดูลใน guest แทบไม่ช่วย การคอมไพล์ต้องใช้การกำหนดค่าของเคอร์เนลที่รันอยู่จริง และ /proc/config.gz เป็นทางเลือกและมักไม่มีในอิมเมจขนาดเล็ก แม้โมดูลที่ใช้งานได้ก็ไม่สามารถใส่เข้าเคอร์เนลที่คอนเทนเนอร์ไม่ได้เป็นเจ้าของ
เมื่ออุปกรณ์ปรากฏ ให้รีสตาร์ทเซอร์วิสและยืนยันอินเทอร์เฟซก่อนทดสอบทราฟฟิก การเห็น tun0 แสดงว่าเดมอนเปิดอุปกรณ์แล้ว มันยังไม่บอกอะไรเกี่ยวกับการส่งต่อ กฎไฟร์วอลล์ หรือเส้นทางที่ไคลเอ็นต์ได้รับ
นี่เป็นคำถามแยกกันพร้อมหลักฐานแยกกัน อุปกรณ์ที่หายไปคือความล้มเหลวของเงื่อนไขเบื้องต้น อุโมงค์ที่มีอยู่แต่ไม่บรรทุกอะไรเลยคือความล้มเหลวของนโยบาย